On Mon, Aug 31, 2020 at 09:35:19PM -0400, wrote:
> On Mon, Aug 31, 2020 at 10:35:12AM -0700, Jesse Brandeburg wrote:
> > Thanks for the report Lennart, I understand your frustration, as this
> > should probably work without user configuration.
> >
> > However, please give this command a try:
> >
On Mon, Aug 31, 2020 at 10:35:12AM -0700, Jesse Brandeburg wrote:
> Thanks for the report Lennart, I understand your frustration, as this
> should probably work without user configuration.
>
> However, please give this command a try:
> ethtool --set-priv-flags ethX disable-source-pruning on
Hmm,
On Thu, Aug 27, 2020 at 02:30:39PM -0400, Lennart Sorensen wrote:
> I have hit a new problem with the X722 chipset (Intel R1304WFT server).
> VRRP simply does not work.
>
> When keepalived registers a vmac interface, and starts transmitting
> multicast packets with the vrp me
I have hit a new problem with the X722 chipset (Intel R1304WFT server).
VRRP simply does not work.
When keepalived registers a vmac interface, and starts transmitting
multicast packets with the vrp message, it never receives those packets
from the peers, so all nodes think they are the master. tc
On Tue, May 21, 2019 at 09:51:33AM -0700, Alexander Duyck wrote:
> I think we need to narrow this down a bit more. Let's try forcing the
> lookup table all to one value and see if traffic is still going to
> queue 0.
>
> Specifically what we need to is run the following command to try and
> force
On Fri, May 17, 2019 at 03:20:02PM -0700, Alexander Duyck wrote:
> I was hoping it would work too. It seemed like it should have been the
> answer since it definitely didn't seem right. Now it has me wondering
> about some of the other code in the driver.
>
> By any chance have you run anything li
On Thu, Nov 08, 2018 at 01:50:23PM -0800, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> [ Upstream commit afc9d590b8a150cfeaac0078ef5de6fb21a5ea6a ]
>
> Errata i856 for the AM572x (DRA7xx) points out that the 3
On Wed, Mar 21, 2018 at 04:31:03PM +, Ben Hutchings wrote:
> On Wed, 2018-03-21 at 17:04 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Feb 12, 2018 at 10:43:25AM -0500, Lennart Sorensen wrote:
> > > Commit 9a0be5af added a reference to vsyscall_pgprot in
> > > arch/
On Wed, Mar 07, 2018 at 05:50:43PM -0500, Theodore Y. Ts'o wrote:
> Yes, this is a shortcoming in tune2fs. You can set extended mount
> options using debugfs:
>
> debugfs -w -R "set_super_value mount_opts foo,bar" /dev/sda1
>
> ... but there ought to be some way to support some kind of quoti
On Wed, Mar 07, 2018 at 11:08:56AM -0500, Theodore Y. Ts'o wrote:
> This is where it's critcal to understand that the "tune2fs -o" changes
> the *default* mount options. The key in the comment is the anything
> different from the *filesystem* defaults (that is, the defaults of the
> particular ext
On Wed, Mar 07, 2018 at 11:08:56AM -0500, Theodore Y. Ts'o wrote:
> This is where it's critcal to understand that the "tune2fs -o" changes
> the *default* mount options. The key in the comment is the anything
> different from the *filesystem* defaults (that is, the defaults of the
> particular ext
On Tue, Mar 06, 2018 at 11:06:08PM -0500, Theodore Y. Ts'o wrote:
> On Tue, Mar 06, 2018 at 02:03:15PM -0500, Lennart Sorensen wrote:
> > While switching a system from using ext3 to ext4 (It's about time) I
> > discovered that setting default options for the filesystem usi
While switching a system from using ext3 to ext4 (It's about time) I
discovered that setting default options for the filesystem using tune2fs
-o doesn't work for the root filesystem when mounted by the kernel itself.
Filesystems mounted from userspace with the mount command use the options
set just
Commit 9a0be5af added a reference to vsyscall_pgprot in
arch/x86/mm/kaiser.c but that is undefined if X86_VSYSCALL_EMULATION=n
which on an embedded system where you know how all your software is
compiled is quite likely.
Of course the condition is always false with that config so the code
will nev
On Wed, Jan 03, 2018 at 03:47:35PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> > When the linux kernel is build with (typical kernel ship with Debian
> > installer):
> >
> > CONFIG_FB_OF=y
> > CONFIG_VT_HW_CONSOLE_BINDING=y
> > CO
On Tue, Sep 19, 2017 at 09:41:02PM +0200, Benjamin Poirier wrote:
> On 2017/09/19 12:38, Philip Prindeville wrote:
> > Hi.
> >
> > We’ve been running this patchset (all 5) for about as long as they’ve been
> > under review… about 2 months. And in a burn-in lab with heavy traffic.
> >
> > We’ve
s needs checking and link status is
> > down.
> >
> > Avoid the problem by using the return value of .check_for_link to signal
> > the link status to e1000e_has_link().
> >
> > Reported-by: Lennart Sorensen
> > Signed-off-by: Benjamin Poirier
> &g
On Thu, Jul 20, 2017 at 04:44:55PM -0700, Benjamin Poirier wrote:
> Could you please test the following patch and let me know if it:
> 1) reduces the interrupt rate of the Other msi-x vector
> 2) avoids the link flaps
> or
> 3) logs some dmesg warnings of the form "Other interrupt with unhandled [.
/* link_active is false, wrongly */
>
> This problem arises because the single flag get_link_status is used to
> signal two different states: link status needs checking and link status is
> down.
>
> Avoid the problem by using the return value of .check_for_link to signal
&g
en there is overrun. Instead, we wait until
> traffic subsides, napi polling mode is exited and interrupts are
> re-enabled.
>
> Reported-by: Lennart Sorensen
> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
> Signed-off-by: Benjamin Poirier
Any chance of this fix hitting -stable? After all adapter reset under
load is not nice.
--
Len Sorensen
On Fri, Jul 21, 2017 at 11:27:09AM -0400, wrote:
> On Thu, Jul 20, 2017 at 04:44:55PM -0700, Benjamin Poirier wrote:
> > Could you please test the following patch and let me know if it:
> > 1) reduces the interrupt rate of the Other msi-x vector
> > 2) avoids the link flaps
> > or
> > 3) logs some
On Thu, Jul 20, 2017 at 04:44:55PM -0700, Benjamin Poirier wrote:
> Could you please test the following patch and let me know if it:
> 1) reduces the interrupt rate of the Other msi-x vector
> 2) avoids the link flaps
> or
> 3) logs some dmesg warnings of the form "Other interrupt with unhandled [.
On Wed, Jul 19, 2017 at 05:07:47PM -0700, Benjamin Poirier wrote:
> Are you sure about this? In my testing, while triggering the overrun
> with the msleep, I read ICR when entering e1000_msix_other() and RXO is
> consistently set.
I had thousands of calls to e1000_msix_other where the only bit set
On Tue, Jul 18, 2017 at 04:14:35PM -0700, Benjamin Poirier wrote:
> Thanks for the detailed analysis.
>
> Refering to the original discussion around this patch series, it seemed like
> the IMS bit for a condition had to be set for the Other interrupt to be raised
> for that condition.
>
> https:/
Commit 16ecba59bc333d6282ee057fb02339f77a880beb has apparently broken
at least the 82574L under heavy load (as in load heavy enough to cause
packet drops). In this case, when running in MSI-X mode, the Other
Causes interrupt fires about 3000 times per second, but not due to link
state changes. Un
On Tue, May 16, 2017 at 11:27:08AM -0400, Kevin McKinney wrote:
> Hi Everyone,
>
> Would it be possible to have a custom block device driver read/write
> in increments of 12k instead of reading/writing data in 4k increments?
> In other words, I would like to change the default page size on a
> x86
On Thu, Mar 23, 2017 at 10:02:23PM +0100, Stephen Mueller wrote:
> Looks like it worked! Thanks!
Well at least you could backup the data, just in case.
> I used:
>
> sudo mdadm --create /dev/md0 --assume-clean --verbose --level-10
> --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf
I wonder
On Thu, Mar 23, 2017 at 09:09:39PM +0100, Stephen Mueller wrote:
> OK, I used gdisk to remove the GPT and MBR from each disk.
> mdadm --assemble still doesn't work... says it can't find the
> superblock. The mdadm --examine commands also say that no
> superblock is detected.
Yes the GPT overwrite
On Thu, Mar 23, 2017 at 08:38:08PM +0100, Stephen Mueller wrote:
> Apologies, I should have started this on linux-raid...
>
>
> stephen@fred> sudo gdisk -l /dev/sdc
> GPT fdisk (gdisk) version 1.0.1
>
> Partition table scan:
> MBR: protective
> BSD: not present
> APM: not present
> GPT:
On Thu, Mar 23, 2017 at 07:09:41PM +0100, r...@mueller.org wrote:
> Thank you very much or your reply.
>
> I naively thought that starting without partitions would be the best
> starting point, given 3 of the disks had been in a RAID5 array
> previously (possibly with partitions, not sure), but th
On Thu, Mar 23, 2017 at 05:49:05PM +0100, r...@mueller.org wrote:
> I am hoping someone here will help me. Was reading this site...
>
> https://raid.wiki.kernel.org/index.php/Linux_Raid
>
> and it said to email this list if you've tried everything other than mdadm
> --create.
>
>
> I am running
On Mon, Dec 19, 2016 at 01:09:39PM -0500, Lennart Sorensen wrote:
> I am trying to debug a problem that has been happening occationally for
> years on some of our systems running 3.0.101 kernel (yes I know it is
> old, we are moving to 4.9 at the moment but I would like older release
On Thu, Nov 24, 2016 at 09:11:41AM -0800, Andy Lutomirski wrote:
> I gett this when booting a 32-bit 4.9-rc6-ish on Skylake:
>
> [0.564506] [ cut here ]
> [0.564994] WARNING: CPU: 0 PID: 1 at
> ./arch/x86/include/asm/fpu/internal.h:368 fpu__restore+0x203/0x210
> [
I am trying to debug a problem that has been happening occationally for
years on some of our systems running 3.0.101 kernel (yes I know it is
old, we are moving to 4.9 at the moment but I would like older releases
to be fixed too, assuming 4.9 makes this problem disappear).
What is happening is th
On Fri, Oct 21, 2016 at 01:36:52PM -0500, David Lechner wrote:
> This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI
> AM1808
> based board.
>
> This patch series has been tested working (along with some hacks to fix the
> GPIOs) on an EV3.
>
> There are still quite a few ad
On Wed, Sep 28, 2016 at 09:05:44AM -0500, Steve Kenton wrote:
> I decided to experiment with /sys/bus/pci and the BIOS settings to try
> and understand things better.
>
> The BIOS has a settings to enable/disable the on-board LAN. When the
> Blackmagic card firmware is upgraded
> bus[03] and hence
On Wed, Sep 28, 2016 at 09:26:42PM -0500, Larry Finger wrote:
> By the time it gets slow, the CPU's cool, and one cannot see the temp just
> before that event happened.
Hmm, I would not expect the CPU to drop from 80 to 40 degrees in a few
seconds if the fan is not spinning. I wouldn't even expec
On Mon, Sep 26, 2016 at 04:28:29PM -0500, Larry Finger wrote:
> Mostly I use a KDE applet named "System load" and look at the "average
> clock", but the same info is also available in /proc/cpuinfo as "cpu MHz".
> When the bug triggers, the system gets very slow, and the cpu fan stops even
> though
On Sat, Sep 24, 2016 at 07:24:14PM -0500, Steve Kenton wrote:
> I have two different systems with Blackmagic Design Intensity Pro-4K
> cards. One uses an ECS H81H3-I motherboard and the other uses a Gigabyte
> GA-H110N motherboard. Previously both were working properly. When I
> upgraded the Blackm
On Fri, Sep 16, 2016 at 01:32:05PM -0700, Guenter Roeck wrote:
> On Fri, Sep 16, 2016 at 09:03:20PM +0100, Al Viro wrote:
> > On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> > > Hi,
> > >
> > > I see the following runtime failure when running a 'sh' image with qemu
> > > in -next
On Thu, Sep 01, 2016 at 02:58:13PM -0700, Greg wrote:
> On Thu, 2016-09-01 at 22:14 +0200, Pavel Machek wrote:
> > Hi!
> >
> > I have trouble getting 1000mbit out of my ethernet card.
> >
> > I tried direct connection between two PCs with different cables, and
> > no luck.
> >
> > Today I tried
On Thu, Aug 25, 2016 at 09:38:39AM +0200, Ralph Sennhauser wrote:
> I'm also not interested in a never ending thread. It's moot that udev
> can't rename to kernel names sanely and we were sold ep34aj17asz98 as
> the replacement. Or that tearing apart the casing to replace the wifi
> modules with an
On Wed, Aug 24, 2016 at 09:52:00PM +0200, Thomas Petazzoni wrote:
> I'll let the platform maintainers decide what's the least
> intrusive/problematic option. Both solutions have drawbacks, so it's
> really a "political" decision to make here.
I think the main valid argument for a revert is that it
On Wed, Aug 24, 2016 at 01:10:23PM -0400, Lennart Sorensen wrote:
> Well certainly doing udevtrigger -n -v I see no ethernet devices (but
> lots of other things). Looking in sysfs it is possible to dereive which
> ethX belongs to which port based on the directory names, but that's
On Wed, Aug 24, 2016 at 08:14:44PM +0200, Thomas Petazzoni wrote:
> Depends on the network driver I believe. But with an e1000e NIC plugged
> in a PCIe slot, it indeed gets assigned as eth0, and the internal
> mvneta devices get eth1, eth2, etc.
Which of course means the change does not actually e
On Wed, Aug 24, 2016 at 07:10:04PM +0200, Ralph Sennhauser wrote:
> And in how many places this discrepancy was documented? You won't be
> able to update them all. Mailing lists, blogs, fora posts and what ever
> else. I'd say the damage is done and can't be fixed by simply changing
> the order now
On Wed, Aug 24, 2016 at 06:43:34PM +0200, Thomas Petazzoni wrote:
> Well, just like the for the documentation aspect, you're seeing this
> from the OpenWRT/LEDE angle only. Other people are using plenty of
> other things.
>
> We knew it would potentially cause some breakage, so it was a
> trade-of
On Wed, Aug 24, 2016 at 04:50:11PM +0200, Thomas Petazzoni wrote:
> We had many many users getting confused by the fact that the order of
> the network interfaces was inverted compared to:
>
> * The board documentations
> * The U-Boot numbering
> * And to a lesser extent, the vendor kernel
>
>
On Wed, Aug 24, 2016 at 04:42:20PM +0200, luigi.gen...@it.telecomitalia.it
wrote:
> Hi all,
>
> recentrly I was in need to compile and run linux kernel 3.19.8 on some
> servers, with different bios and cpus.
>
> so i noticed that If i compile this kernel with binutils 2.6 (and 2.7) it
> does not
On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote:
> Sadly, sizeof is what we use when copying that sucker to userland. So these
> padding bits in the end would've leaked, true enough, and the case is somewhat
> weaker. And any normal architecture will have those, but then any such
> archit
On Tue, Aug 23, 2016 at 01:34:05PM -0700, Joe Perches wrote:
> On Tue, 2016-08-23 at 21:09 +0100, Al Viro wrote:
> > On Tue, Aug 23, 2016 at 11:24:06AM -0700, David Miller wrote:
> > ... and then we can file a bug report against the sodding compiler. Note
> > that
> > struct ethtool_wolinfo {
> >
On Fri, Jun 24, 2016 at 07:58:32PM +0300, Grygorii Strashko wrote:
> Oh. nice :( So, seems, I'd need to send v3. Right?
> By the way, this code hasn't been introduced by this patch - I've
> just moved whole function from one place to another.
Well since it is moving I would think that was a handy
On Fri, Jun 24, 2016 at 11:35:15AM +0530, Mugunthan V N wrote:
> >> +static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
> >> +{
> >> +if (!pool)
> >> +return;
> >> +
> >> +WARN_ON(pool->used_desc);
> >> +if (pool->cpumap) {
> >> +dma_free_coherent(pool->de
On Mon, Jun 13, 2016 at 05:46:19PM +0200, Sebastian Frias wrote:
> My understanding of "hierarchical irq domains" is that it is useful when
> there are multiple stacked interrupt controllers.
> Also, the documentation says "the majority of drivers should use the linear
> map" (as opposed to the h
On Mon, Jun 13, 2016 at 05:49:55PM +0200, Mason wrote:
> If I am not mistaken, the Cortex A9 MPCore GIC has 32 inputs.
>
> So any SoC with more than 32 devices capable of generating IRQs
> would have to share interrupts, right?
No, you simply add another interrupt controller to cascade it. That
On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the
> GIC.
> The HW block is a many-to-many router.
> There are 128 32bit registers which specify, for each of the corresponding
> 128 inputs, to which of t
On Sat, Jun 11, 2016 at 05:37:51PM +0200, Mason wrote:
> Only the name of the file was provided, not the path. I was not aware
> that you already knew where to find it. I made no claim whatsoever on
> the implementation. In fact, I agree with everything Lennart wrote.
The way the TI irq crossbar w
On Fri, Jun 10, 2016 at 05:37:30PM +0200, Sebastian Frias wrote:
> We are trying to write a driver for an interrupt controller (actually more of
> a crossbar) for an ARM-based SoC.
> This IRQ crossbar has 128 inputs and 24 outputs, the outputs are connected
> directly to the GIC.
> The idea is th
On Thu, May 05, 2016 at 04:44:44PM -0400, Lennart Sorensen wrote:
> powerpc: Fix sstep compile on powerpcspe
>
> Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx
> into the instructions in sstep.c, which are not accepted by the assembler
> on powerpcspe, b
powerpc: Fix sstep compile on powerpcspe
Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx
into the instructions in sstep.c, which are not accepted by the assembler
on powerpcspe, but does seem to be accepted by the normal powerpc assembler
even in 32 bit mode.
Wrap these
On Fri, May 29, 2015 at 12:31:57PM -0400, Nicholas Krause wrote:
> This removes the function, cpsw_ale_flush and its prototype from the
> files cpsw_ale.c and cpsw_ale.h due to having no more callers. Finally
> we also remove the functions, cpsw_ale_set_vlan_entry,
> cpsw_ale_flush_ucast and cpsw_
commit ace3fc1e3f3a85ec705805146247231b11e1babe in 3.12.40 missed two
lines while pulling in commit 8a45ac12ec5b6ee67f8559c78ae11d9af8b821ee
from upstream. This causes the tests to fail in some cases.
With the two missing lines added in, the tests pass again.
Tested with omap-aes, omap-sham and
On Wed, Apr 15, 2015 at 11:51:32AM -0500, Nishanth Menon wrote:
> I am yet to post a new revision to this series - few other stuff got
> in the way. IODelay driver in no way removes the constraint that the
> SoC architecture has - most of the pins still need to be muxed in
> bootloader - we cannot
On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote:
> Yeah agreed. I suggest discussing the binding and the generic
> parsing code for it first :)
>
> It seems with the generic binding the actual driver should be
> just the hardware specific code hopefully.
Did this thread go anywhere
On Sat, Dec 20, 2014 at 09:08:51AM -0800, Florian Fainelli wrote:
> 2014-12-18 19:49 GMT-08:00 Lennart Sorensen :
> > I have been trying to move an 8360 based system from a 3.0 kernel to a
> > 3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an
> > oops i
On Mon, Jan 26, 2015 at 01:40:34PM +0100, Johan Hovold wrote:
> On Wed, Jan 21, 2015 at 03:24:27PM -0500, Lennart Sorensen wrote:
> > Added the USB serial console device ID for Siemens Ruggedcom devices
> > which have a USB port for their serial console.
> >
> >
On Mon, Jan 12, 2015 at 05:20:31PM +0100, Tobias Powalowski wrote:
> I have a weird bug here with initramfs,
> I have big initramfs files around 150MB zipped, 400MB extracted.
> I suppose the needed RAM to boot this setup should be around:
> 150MB zipped initramfs+ 400MB extracted initramfs + 5MB k
Added the USB serial console device ID for Siemens Ruggedcom devices
which have a USB port for their serial console.
Signed-off-by: Len Sorensen
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index
On Tue, Jan 06, 2015 at 05:41:35PM -0600, Rob Landley wrote:
> From: Rob Landley
>
> Commit e6023367d779 added perl back to the kernel build in -rc6.
> Replace 39 lines of perl with 4 lines of shell script.
Maybe checkpatch should be updated to look for perl. :)
--
Len Sorensen
--
To unsubscri
On Thu, Jan 01, 2015 at 12:14:15PM -0800, Linus Torvalds wrote:
> So I'm not saying "ifconfig is wonderful". It's not.
>
> But I *am* saying that "changing user interfaces and then expecting
> people to change is f*cking stupid".
>
> The fact is, ifconfig is simple for the simple cases, but more
On Wed, Dec 31, 2014 at 01:57:59PM -0800, Linus Torvalds wrote:
> Side note: does anybody think that was really a good idea to begin
> with? I mean, Cisco iOS is just _s_ universally loved, right?
>
> And yeah, I refuse to use "ip link" or other insane commands. Let's
> face it, "ifconfig" and
On Sun, Dec 21, 2014 at 11:03:24AM -0800, Joe Perches wrote:
> On Sun, 2014-12-21 at 19:47 +0100, Bruno Prémont wrote:
> > On Sat, 20 December 2014 dwal...@fifo99.com wrote:
> > > This adds to to the console= command line options allowing the
> > > addition of a per console log level setting.
> > >
On Sat, Dec 20, 2014 at 09:08:51AM -0800, Florian Fainelli wrote:
> There are some comments in ucc_geth that also lead me to believe this
> is a just a hack instead of a real Ethernet PHY device. Part of what I
> think got broken is because of this comment:
>
> /* Initialize TBI PHY interface for
If the boot loader enables HYP mode on the boot CPU, the secondary CPU
also needs to call into the ROM to switch to HYP mode before booting.
The firmwares on the omap5 and dra7xx unfortunately do not take care
of this, so it has to be handled by the kernel.
This patch is based on "[PATCH 2/2] ARM:
I have been trying to move an 8360 based system from a 3.0 kernel to a
3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an
oops in the ucc_geth driver when using RTBI mode on one of the ucc
ports. I haven't managed to find any commits to of_mdio or ucc_geth or
fsl_pq_mdio that w
On Wed, Dec 17, 2014 at 05:45:05PM +0200, Tero Kristo wrote:
> Yea clock mux can be used. However, we don't have support for DRA7
> control module clocks in the DT yet. I have posted patches with
> support towards this a couple of weeks back, but they need some
> revising.
>
> Thus, we maybe need
On Wed, Dec 17, 2014 at 09:22:25AM -0600, Nishanth Menon wrote:
> A clock mux might do the job?
>
> value 1, 2 , 3 will imply sysclk1 / 610
> value of 0 implies fixed 32768
>
> soemthing like
> sys_clk32_crystal {
>compatible = "fixed-clock";
>clock-frequency = <32
On Wed, Dec 17, 2014 at 03:21:27PM +0200, Tero Kristo wrote:
> Yea I think the 32k clock node should be fixed based on this.
> Something like this:
>
> --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
> @@ -100,8 +100,10 @@
>
> sys_32k_ck: sys_32k_ck
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Fixes: fa6d79d27614 ("ARM: OMAP: Add initialisation for the real-time
counter")
Signed-off-by: Len Sorensen
Reviewed-by: Lokesh Vutla
Acked-by: Nishanth Menon
---
arch/arm/mach-omap2
While trying to deal with errata i856 on the dra7xx I encountered some
obvious typos in the frequencies checked in timer.c, so those are being
fixed in case anyone ever tries to use one of them.
Also implement a fix for errata i856. Without the fix the time on the
system will get ahead by 43 seco
On Tue, Dec 16, 2014 at 01:56:16PM -0600, Nishanth Menon wrote:
> *AM*57xx is not *OMAP*57xx -> there is no OMAP57xx.
Oh OK. Thanks for clearing that up.
> AM57xx and DRA7xx are in the same generation of processors and is
> derivative technology (not the same) as OMAP5432/OMAP5430.
>
> We have
> I see why arch_timer_freq might skip the rounding error of 39, 15 and
> 55 Vs existing logic which is possibly at a truncation error risk
> (without errata for sysclk 13, 26 and 27MHz).
>
> all you'd probably need to do is cast rate, num and den to unsigned
> long and have a common computation l
On Tue, Dec 16, 2014 at 08:06:34AM -0600, Nishanth Menon wrote:
> On 12/12/2014 04:08 PM, Lennart Sorensen wrote:
> > The switch statement of the possible list of SYSCLK1 frequencies is
> > missing a 0 in 4 out of the 7 frequencies.
> >
> > Signed-off-by: Len Sorensen
On Tue, Dec 16, 2014 at 08:58:56AM -0600, Nishanth Menon wrote:
> On 17:05-20141216, Lokesh Vutla wrote:
> [...]
> >
> > @@ -545,6 +546,16 @@ static void __init realtime_counter_init(void)
> > break;
> > }
> >
> > + if (soc_is_dra7xx()) {
> > + reg = omap_ctrl_readl(
On Tue, Dec 16, 2014 at 05:05:08PM +0530, Lokesh Vutla wrote:
> Is this applicable for OMAP5 also?
> If not can you drop omap5 from $subject?
DRA7xx = OMAP57xx, which to me is an omap5. Isn't it?
And I haven't been able to get a manual for the omap54xx to confirm it,
although it seems it does no
On Fri, Dec 12, 2014 at 05:08:56PM -0500, Lennart Sorensen wrote:
> Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
> crystal is not enabled at power up. Instead the CPU falls back to using
> an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 i
While trying to deal with errata i856 on the dra7xx I encountered some
obvious typos in the frequencies checked in timer.c, so those are being
fixed in case anyone ever tries to use one of them.
Also implement a fix for errata i856. Without the fix the time on the
system will get ahead by 43 seco
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Signed-off-by: Len Sorensen
---
arch/arm/mach-omap2/timer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-om
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but
On Fri, Dec 12, 2014 at 01:40:01PM -0600, Nishanth Menon wrote:
> we try and avoid soc_is or cpu_is as much as possible and depend usually
> on compatible to mark the change..
Well you can't use the dtb really, since it depends on the chip revision
and how it started at power on. After all if you
On Fri, Dec 12, 2014 at 11:37:41AM -0600, Nishanth Menon wrote:
> -sricharan, as the email ID is defunct.
So I noticed.
> On 12/11/2014 02:43 PM, Lennart Sorensen wrote:
> > On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
> >> Errata i856 for the AM572x (DR
On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
> Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
> crystal is not enabled at power up. Instead the CPU falls back to using
> an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 i
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but
On Thu, Nov 13, 2014 at 07:34:09PM +0100, Sebastian Andrzej Siewior wrote:
> misaligned dma? I haven't seen any alignment requirement for SDMA/EDMA
> and I haven't seen this error on beagle board, am335x-evm or dra7-evm.
Well I am using the am5728, so it should be the same as the dra7-evm.
> So b
On Thu, Nov 06, 2014 at 10:18:22AM -0600, Nishanth Menon wrote:
> BeagleBoard-X15 is the next generation Open Source Hardware
> BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15
> processor. The platform features 2GB DDR3L (w/dual 32bit busses),
> eSATA, 3 USB3.0 ports, integrated
On Wed, Nov 05, 2014 at 05:30:51PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/05/2014 05:20 PM, Lennart Sorensen wrote:
> > On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
> >> Two systems ran 16 hours each so far with no issues. Pushed 170MB of
> >
On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
> Two systems ran 16 hours each so far with no issues. Pushed 170MB of
> data through the pair of serial ports on one system at 230400.
The console on uart3 doesn't appear to be using the dma assuming the
values in /
On Wed, Nov 05, 2014 at 09:11:35AM +0100, Sebastian Andrzej Siewior wrote:
> Okay. No DMA but the basic part seems to work for you. Thanks for
> testing.
Two systems ran 16 hours each so far with no issues. Pushed 170MB of
data through the pair of serial ports on one system at 230400.
--
Len So
On Tue, Nov 04, 2014 at 04:03:15PM -0500, Lennart Sorensen wrote:
> So it seems to be working on our board so far. Will stress test it
> some more. No DMA of course for now, but oh well.
Well 4 hours running with multiple reboots (our testsuite reboots every
30 minutes to test the wa
1 - 100 of 499 matches
Mail list logo
