On Tue, Nov 27, 2012 at 09:41:51AM +0100, Tim Sander wrote:
> Hi
>
> I have been trying to get the 3.7-rc6 kernel to compile for a beaglebone
> board
> with device tree but it seems there are still bits missing. Especially it
> seems as if the sd card reader and network is not working properly?
On Tue, Nov 27, 2012 at 03:23:51PM +0100, Yegor Yefremov wrote:
>
> How do you load your rootfs: embedded into kernel or separately?
Separately. I gave up on the embedded option on ARM (IXP) long ago,
since I never could getaw it to work.
> Do you know if frame buffer is functioning in main lin
On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote:
>
> Another pesky BIOS which changes the display state behind our back on lid
> closing! Should be duct-tapped over with
>
> commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> Author: Daniel Vetter
> Date: Fri Nov 23 18:16:34 2012 +
On Mon, Mar 18, 2013 at 09:58:46AM +0800, wwang wrote:
> Hi Richard:
>
> Could you please describe the detailed model of your 4G card? It
> would be better if you can take a picture of that card or give me
> the Amazon link of it. It looks like a compatibility issue.
The lettering on the card is:
On Thu, Mar 21, 2013 at 12:22:57PM +0400, Konstantin Khlebnikov wrote:
> This patch adds new kind of dependencies between kconfig symbols,
> and new kconfig keyword 'apply' for them.
>
> 'apply' works mostly like 'select', but it allows to disable target symbol.
> Thus target symbol will be either
On Thu, Mar 21, 2013 at 03:06:11PM +0400, Konstantin Khlebnikov wrote:
>
> As I see this technology requires special dedicated server in the local
> network, thus it's unusable in most situations. But it starts working
> without any actions from the user (please fix me if I'm wrong).
Perhaps you
On Wed, Apr 03, 2013 at 10:50:57AM -0700, John Stultz wrote:
>
> I get the reasoning around reusing the fd we already have, but is
> the possibility of a dynamic chardev pathname really a big concern?
I have been following this thread, and, not knowing very much about
perf, I would think that the
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
>
> It's a lot of code for a 50ms boot-time improvement. Does anyone have
> any opinions on whether or not the benefits are worth the cost?
In the embedded space, quick boot is a really important feature to
have. Many people resort t
asked me
whether to enable this 'new' option. That is really annoying,
especially with non-atom and non-x86 builds.
Ben, you removed the PCH_GBE dependency in 18d359ce. Are you sure that
was the right thing to do?
Thanks,
Richard
> Cc: Richard Cochran
> Signed-off-by: Jeff Mahon
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote:
> Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
> While at it, added a non-NAPI mode (which is easier to debug), plus
> some general fixes.
I have a few issues with this patch:
1. This is a networking
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote:
> Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
> While at it, added a non-NAPI mode (which is easier to debug), plus
> some general fixes.
This patch does not apply to net-next.
When you do post to n
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote:
> Hi Richard,
>
> Yes, I guess this was more of a drive-by patch dump - but people need this
> to get PG2.0 silicon to work on am33xx.
And what is PG2.0?
> And no, I don't think having a non-NAPI code path is backwards, especiall
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote:
>
> Speaking of which, I'm probably the original developer of the fec driver.
BTW, as I mentioned, someone is converting fec to napi. Care to take a
look to make sure it is done right?
Thanks,
Richard
--
To unsubscribe from this
I have an Acer Aspire One netbook, and on it I get the following
warning when closing and opening the lid. I think this warning first
appeared in 3.7.
Does this need fixing? If so, who can do it?
Thanks,
Richard
** close lid
Mar 16 11:32:03 netboy kernel: [ 287.429404] [drm:i9xx_crtc_mode_set
I have an Acer Aspire One netbook with a built in card reader, and I
have two cards, one with 32 MB and one with 4 GB. The card reader used
to work with the staging driver in 3.7.10, but the new 3.8.3 driver
does not work with the larger card. The old driver was removed in
commit cd211222.
Now, w
On Tue, Oct 23, 2012 at 01:03:09PM -0700, Kees Cook wrote:
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Richard Cochran
> Signed-off-by: Kees Cook
On Sat, Sep 22, 2012 at 06:16:49PM +0200, Christophe Leroy wrote:
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
> precautions linked to ERRATA Item 4:
>
> Revision A2 of LXT973 chip randomly returns the contents of the previous even
> register when you read a odd
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
> diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
> --- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
> +++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
> @@ -175,6 +292,16 @@
> .
On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote:
>
> A2 chip has phy_id 0x00137a10
> A3 chip has phy_id 0x00137a11
Okay then, thanks.
Acked-by: Richard Cochran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote:
>
> Don't get me wrong. If I had time for this it could be different.
> Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at
> this point. Given the raised barriers to participate, probably aimed at
> paid mainta
On Thu, Jul 11, 2013 at 02:22:14PM -0700, Mark Galeck wrote:
> >The answer to "is it desirable to improve X?" is always "yes." But
>
> the only way to make progress in Linux is to actually post patches
> that "improve X." This is unlike many corporate environments, where
> you might need to get
On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
> This patch add a method into testptp.c to measure the time offset
> between phc and system clock through the ioctl PTP_SYS_OFFSET.
>
This is a nice addition to the testptp program. I do have a few
comments, below.
First off, the subject
On Sat, Sep 14, 2013 at 11:39:52PM +0800, Dong Zhu wrote:
> On Sat, Sep 14, 2013 at 04:31:46PM +0200, Richard Cochran wrote:
> > On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
> > > This patch add a method into testptp.c to measure the time offset
> > > b
set tx time
> stamp.
>
> The issue were introduced by commit eda297729171fe16bf34fe5b0419dfb69060f623
> (tun: Support software transmit time stamping).
>
> Cc: Richard Cochran
> Signed-off-by: Jason Wang
Acked-by: Richard Cochran
--
To unsubscribe from this list: send t
ach. This patch fixes this.
>
> Cc: Richard Cochran
> Signed-off-by: Jason Wang
Acked-by: Richard Cochran
--
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.o
On Mon, Sep 09, 2013 at 10:47:01AM -0700, Andy Lutomirski wrote:
>
> I think that coming up with something that's both non-POSIX and
> half-arsed is a bad idea, but doing something that's non-POSIX and
> well thought-through could be valuable.
I know Harlan Stenn of the Network Time Foundation is
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
On Mon, Sep 10, 2012 at 05:45:49PM +0200, Christophe Leroy wrote:
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
> precautions linked to ERRATA Item 4:
I have a few nit picking remarks, below...
> Item 4: MDIO Interface and Repeated Polling
> Problem: Repeated p
On Sat, Oct 06, 2012 at 10:07:23PM +0800, Haicheng Li wrote:
>
> IMHO, the reason why the dependency of PCH_PTP becomes so tricky is
> that the code of these two modules call the functions of each other
> (bad code structure?).
Yes, that is the source of the problem. I don't recall how this habit
;chip->regs' was not released
> on error
>
> Cc: Richard Cochran
> Cc: David S. Miller
> Signed-off-by: Yuanhan Liu
Acked-by: Richard Cochran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
On Sun, Oct 21, 2012 at 02:02:42PM +0800, caiyuqing wrote:
> hi, all.
> I have some questions about context switch on arm Linux (my target is
> ARMv7-a).
> 1. Does arm linux support FCSE to handle the context switch?
No, mainline Linux does not support FCSE. However, you can use Gilles'
unoffical
On Sun, Oct 21, 2012 at 04:19:50PM +0800, caiyuqing wrote:
> Richard, thanks for your reply.
> mainline Linux doesn't support FCSE, if so, when kernel switch a
> process to another(these two process share the same virtual memory
> space), that means the vitrual-to-physical address should be
> remap
On Thu, Jan 03, 2013 at 11:20:52AM +0100, Julia Lawall wrote:
> There has been a discussion recently about how the result of get_clk
> should be an opaque handle, not a value that can be dereferenced:
>
> https://lkml.org/lkml/2012/12/20/105
>
> There is such a dereference in drivers/net/ethernet
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote:
> The following patchset introduces Device Tree overlays, a method
> of dynamically altering the kernel's live Device Tree.
It would be nice to know the motivation for this code.
What is the use case? What problem or issue is bein
On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote:
>
> The problem being addressed is discussed in this thread:
> http://permalink.gmane.org/gmane.linux.kernel/1389017
Thanks for the link.
Since the motivation is already documented in that post, why not add
it into Documentation/d
On Tue, Mar 26, 2013 at 12:18:04PM +0900, kpark3...@gmail.com wrote:
> From: Sahara
>
> This fixes a number of sparse warnings like:
> warning: incorrect type in argument 2 (different address spaces)
> expected void volatile [noderef] *addr
> got unsigned int *
>
> warning: Using pla
On Mon, Mar 25, 2013 at 01:08:10PM -0700, John Stultz wrote:
> This patchset makes the lock ownership lines less obvious, but I've
> been sure to keep the ntp state static to ntp.c and instead provided
> some accessors via ntp-internal.h that timekeping code can use to
> make changes. The only re
On Fri, Jul 26, 2013 at 11:36:13AM -0500, Rob Herring wrote:
> On 07/26/2013 10:49 AM, Olof Johansson wrote:
> > On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown wrote:
> >> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> >>
> >>> Unless
On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
>
> Long term, final goal is likely to be close to what Russell is saying
Why is this a long term goal? Start today.
> -- nothing should go into the kernel tree unless the binding is in a
> fully stable state. However, we have a tra
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
>
> Further, every other kernel release tended to break the board.c files,
> just due to the usual kernel churn.
Yes...
> DT is much better, the stuff that can be described in DT is broader
> and more thought tends to have been put
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
> On Fri, Jul 26, 2013 at 06:54:33AM +0200, Richard Cochran wrote:
> > I too work on commercial embedded systems, and DT has proven to be
> > one gigantic *PITA*.
>
> Why do you think our experiences are so d
On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
>
> > [ I disagree about the "more thought" part. The current discussion,
> > coming years too late after the introduction of DT to
On Sat, Jul 27, 2013 at 12:36:02PM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 10:53:01AM +0200, Richard Cochran wrote:
> > On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
>
> > > Why do you think our experiences are so different?
>
> >
On Sat, Jul 27, 2013 at 10:57:09AM -0700, David Lang wrote:
> On Sat, 27 Jul 2013, Richard Cochran wrote:
>
> >On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
> >>On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
> >>
> >>>[ I d
On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
>
> That is a nice summary of how we got from null to now and Richard
> seems to be simply saying: let's stop mucking about and make this a
> project with a well-defined process of dealing with staging and
> stable bindings and keep
On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:
> On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
> >
> > Frankly, I am really surprised and shocked at the cavalier attitude
> > expressed here WRT DT bindings in released kernels. Think about the
>
On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
> I'm not really sure what effect on users this has. Maybe you should define
> "users".
...
> Care to explain this reasoning?
Use Case
User acquires a machine running ARM Linux version 3.x, with u-boot
and dtb in a read onl
On Sun, Jul 28, 2013 at 03:39:56PM +0200, Tomasz Figa wrote:
> There are many possible options:
...
Wow, you totally ignored the use case.
> Please note, though, I'm _not_ trying to convince you that this kind of
> solutions is good, as I'm not convinced either. That's why we are
> discussin
On Sun, Jul 28, 2013 at 10:09:57AM -0400, jonsm...@gmail.com wrote:
>
> 3.z kernel is free to alter the schema. But it will have to supply the
> necessary quirks needed to keep those old dtb's functioning.
The quirks idea sounds okay to me, if it can really provide forward
compatibility. In pract
On Mon, Jul 29, 2013 at 09:31:23AM +0200, Maxime Ripard wrote:
>
> I'm afraid this kind of use case will never be properly supported, DT
> stable ABI or not.
>
> Think about this: what kernel will actually be shipped in that board?
> Most likely, it will be a BSP kernel from the vendor. Does the
On Mon, Jul 29, 2013 at 08:38:52PM +0200, Richard Cochran wrote:
>
> Right, we can and should do better. I got the beaglebone Ethernet
> working in mainline (not by writing the driver, but by complaining
> over and over again). I except that it will continue to
On Wed, Jul 31, 2013 at 12:59:59PM +0200, Tomasz Figa wrote:
> On Wednesday 31 of July 2013 12:37:37 Maxime Bizon wrote:
> >
> > Board files are C code anyone has the skill to edit/understand/refactor.
> > Moving to DT and keep them in tree tightly coupled with the kernel
> > version just adds ano
On Wed, Jul 31, 2013 at 05:23:35PM +0200, Tomasz Figa wrote:
>
> I said it many, many times, that a) and b) I proposed are just two extremes.
> It is unlikely that an extreme solution will be the best option to choose. I
> am strongly for something in the middle, just like I wrote in several of
On Wed, Jul 31, 2013 at 09:29:35PM +0200, Tomasz Figa wrote:
>
> I showed you two example solutions that could handle this use case without
> stable binding ABI, just to prove that b) is not the only option (even if
> it's the best one, which I continue to agree on, don't get me wrong).
You onl
tware Foundation, version 2.
> + *
> + * 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, GOOD TITLE or
> + * NON INFRINGEMENT.
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 modul
e directly
> - Support SIOCSHWTSTAMP ioctl appopriately
> - Rebased to be the last patch in the series to simplify development
Anyhow, this looks much better to me now.
Acked-by: Richard Cochran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
> >
> > I don't think having people "rely" on the bindings is the issue so much
> > as the awareness that if they do, there will be compatibility issues for
> > unstable
On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote:
> On 07/25/2013 11:48 AM, Richard Cochran wrote:
> > On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> >>
> >> As long as we can make sufficiently clear that trying to use an unstable
> &
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> We use DT has a kernel configuration input. Our environment is
> designed to guarantee 100% that the kernel and DT match exactly. DT
> very deliberately isn't an ABI boundary in our systems.
It is nice that you use DT in that way,
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
>
> We use DT has a kernel configuration input. Our environment is
> designed to guarantee 100% that the kernel and DT match exactly. DT
> very deliberately isn't an ABI boundary in our systems.
Think about what you just said.
The
On Wed, Jul 24, 2013 at 03:05:20PM -0700, Greg Kroah-Hartman wrote:
> The dev_attrs field of struct class is going away soon, dev_groups
> should be used instead. This converts the ptp class code to use the
> correct field.
>
> Cc: Richard Cochran
> Signed-off-by:
On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > >
> > > We use DT has a kernel configuration input. Our environment is
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 s
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
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 n
On Fri, Apr 05, 2013 at 07:16:53PM +0100, Pawel Moll wrote:
> Ok, so how about the code below? Disclaimer: this is just a proposal.
> I'm not sure how welcomed would be an extra field in struct file, but
> this makes the clocks ultimately flexible - one can "attach" the clock
> to any arbitrary s
On Mon, Apr 08, 2013 at 12:05:52PM -0700, John Stultz wrote:
>
> So thinking this through further, I'm worried we may _not_ be able
> to eventually enable this to be a vdso as I had earlier hoped.
> Mostly because I'm not sure how the fd -> file -> clock lookup could
> be done in userland (any ide
On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
>
> This should be fixed with the above mentioned patch. The issue is that the
> bios fumbles around with the output configuration behind our backs, so the
> new paranoid modeset code in 3.7+ freaks out about the state mismatch
> betwe
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> It will be only consistent once we've restored all the crtcs. Since a
> bunch of other callers also want to just restore a single crtc, add a
> boolean to disable checking only where it doesn't make sense.
>
> Note that intel_modeset
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>
> It's written against drm-intel-next-queued at
>
> http://cgit.freedesktop.org/~danvet/drm-intel
>
> I've thought that it should apply pretty cleanly against older kernels,
> too. Apparently it conflicts a bit in intel_modeset_set
On Tue, May 07, 2013 at 04:18:23PM +0200, Jiri Slaby wrote:
> From: Jeff Mahoney
>
> 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 reaction was
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
> That patch should crash at all, so this is not expected. Can you pls
> check whether plain drm-intel-nightly is broken, too?
I did try drm-intel-nightly just now (1dd83e3), and it also freezes
the machine. I first verified that the
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
>
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-night
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
>
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-night
On Mon, Aug 27, 2012 at 10:38:33AM -0700, Joe Perches wrote:
> commit ec21e2ec36769 ("freescale: Move the Freescale drivers")
> moved the files, update the pattern.
Thanks for spotting this, Joe.
Acked-by: Richard Cochran
--
To unsubscribe from this list: send the line "uns
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
> On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
> >2. There's nothing vsyscall-specific about the code in
> >vclock_gettime.c. In fact, the VVAR macro should work just fine in
> >kernel code. If you moved all this code into a header, t
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
> I believe its mostly historical, but on some architectures that
> history has become an established ABI, making it technical.
Fine, but what do you mean by "ABI?" Are you talking about magic
addresses for functions?
Without knowing th
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
> On powerpc, I mean magic addresses where userland can find
> structures that it can use to calculate time.
...
> With powerpc, there is no arch specific kernel code involved, its
> just a data structure the kernel exports that is ac
On Wed, Sep 19, 2012 at 02:11:02PM -0700, John Stultz wrote:
> Now, I suspect the difficult part will be finding someone with the
> time and interest to try get the vdso gettime working on ia64 (or
> s390 or powerpc), and then try to unify the kernel side
> implementation. Reducing the maintenance
hvar
Acked-by: Richard Cochran
(Adding John Stultz on CC)
> ---
> kernel/posix-timers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
> index 69185ae..10349d5 100644
> --- a/kernel/posix-timers.c
>
I see the following error, using the .config inline, below.
arch/m68k/mm/init.c: In function 'print_memmap':
arch/m68k/mm/init.c:139:2: error: 'KMAP_START' undeclared (first use in this
function)
arch/m68k/mm/init.c:139:2: note: each undeclared identifier is reported only
once for each function
On Tue, Jan 08, 2013 at 01:59:22PM +0100, Florian Fainelli wrote:
> This patch makes CONFIG_PPS_DEBUG and CONFIG_NTP_PPS be hidden if
> CONFIG_PPS is not selected, such that we are not prompted for these
> configuration options if CONFIG_PPS is not set.
>
> Signed-off-by: Florian Fainelli
> ---
>
On Tue, Sep 20, 2016 at 03:56:38PM -0400, Nicolas Pitre wrote:
> - Add a warning for the case where PTP clock subsystem is modular and a
> driver providing a clock is built-in rather than silently ignoring it.
> Suggested by Jiri Benc.
So I am really not happy with this. Here is a common embe
On Tue, Sep 20, 2016 at 10:25:56PM +0200, Richard Cochran wrote:
> After this series, if I don't pay enough attention to dmesg, then I
> have lost functionality that I had in step #1. That sucks, and it has
> nothing to do with the tinification option at all. It will bite even
On Tue, Sep 20, 2016 at 06:47:02PM -0400, Nicolas Pitre wrote:
> IMHO it is much nicer for the poor user configuring the kernel to have a
> single configuration prompt for PTP support, and then have whatever
> driver that can provide a PTP clock just do it (or omit it) based on
> that single pro
; Signed-off-by: Nicolas Pitre
> Reviewed-by: Eugenia Emantayev
>
> ---
>
> Let's have the basics merged now and work out the actual Kconfig issue
> separately. Richard, if you agree with this patch, I think this could go
> via the netdev tree.
It looks ok to me.
Acked-by: Richard Cochran
On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
> The ALSA API provides support for 'audio' timestamps (playback/capture rate
> defined by audio subsystem) and 'system' timestamps (typically linked to
> TSC/ART) with one option to take synchronized timestamps should the hardwa
On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote:
> Documentation/sound/alsa/timestamping.txt says:
Examples of typestamping with HDaudio:
1. DMA timestamp, no compensation for DMA+analog delay
$ ./audio_time -p --ts_type=1
Where is this "audio_time" pro
On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote:
> Where is this "audio_time" program of which you speak?
Never mind, found it in alsa-lib.
I still would appreciate an answer to my other questions, though...
Thanks,
Richard
On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote:
> > I still would appreciate an answer to my other questions, though...
>
> Currently HD-audio (both ASoC and legacy ones) are the only drivers
> providing the link timestamp. In the recent code, it's PCM
> get_time_info ops, so you ca
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote:
> You can experiment with the 'dma' and 'link' timestamps today on any
> HDaudio-based device. Like I said the synchronized part has not been
> upstreamed yet (delays + dependency on ART-to-TSC conversions that made it
> in the k
On Thu, Sep 08, 2016 at 10:22:43AM +0530, Harini Katakam wrote:
> I cant be sure of the version of Cadence GEM used in SAMA5D2
> but these registers (sub ns increments alteast) only exist in
> the IP version used in Zynq Ultrascale+ MPSoC.
Then you need to find a way to make sure the driver only b
On Thu, Sep 08, 2016 at 10:22:43AM +0530, Harini Katakam wrote:
> >> + /* get GEM internal time */
> >> + sech = gem_readl(bp, TSH);
> >> + secl = gem_readl(bp, TSL);
> >
> > Does reading TSH latch the time? The TRM is silent about that, and
> > most other designs latch on reading the
On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote:
> Also given many other syscalls take clockids and the backing logic
> isn't really getting removed (probably could cut the dynamic posix
> clocks core with the same conditional), I wonder if you could get a
> similar size win by taking a
On Wed, Sep 14, 2016 at 04:02:25PM +0300, Grygorii Strashko wrote:
> @@ -323,7 +307,7 @@ void cpts_rx_timestamp(struct cpts *cpts, struct sk_buff
> *skb)
> u64 ns;
> struct skb_shared_hwtstamps *ssh;
>
> - if (!cpts->rx_enable)
> + if (!cpts || !cpts->rx_enable)
>
On Wed, Sep 14, 2016 at 04:02:26PM +0300, Grygorii Strashko wrote:
> Move DT properties parsing into CPTS driver to simplify consumer's
> code and CPTS driver porting on other SoC in the future
> (like Keystone 2).
And just who is the consumer?
> Signed-off-by: Grygorii Strashko
> ---
> driver
On Wed, Sep 14, 2016 at 04:02:27PM +0300, Grygorii Strashko wrote:
> From: WingMan Kwok
>
> Added return values in tx and rx timestamp funcitons facilitate the
> possibililies of timestamping by CPSW modules other than CPTS, such as
> packet accelerator on Keystone 2 devices.
I'm sorry, this is
On Wed, Sep 14, 2016 at 04:02:28PM +0300, Grygorii Strashko wrote:
> From: WingMan Kwok
>
> When a CPTS user does not exit gracefully by disabling cpts
> timestamping and leaving a joined multicast group, the system
> continues to receive and timestamps the ptp packets which eventually
> occupy a
On Wed, Sep 14, 2016 at 04:02:29PM +0300, Grygorii Strashko wrote:
> @@ -35,6 +33,8 @@ Optional properties:
> For example in dra72x-evm, pcf gpio has to be
> driven low so that cpsw slave 0 and phy data
> lines are connected vi
1 - 100 of 911 matches
Mail list logo
