NLS for HFS and "mount" tool.
I've got no reply so i resend this letter. Roman, i'd like to finish the work and would like to ask you what is wrong with your version of the NLS support for MacHFS. I expected it to appear in v 2.6.12 but there's no it. I would like to proceed basing on it if you insist. Also i would like to ask someone who is responsible for "mount" tool. I'd suggest to modify it in order to support several lines in fstab with the same device and mount points but different filesystems and options. For example: /dev/cdrom /mnt/cdrom udf,iso9660 user,noauto,iocharset=koi8-r 0 0 /dev/cdrom /mnt/cdrom hfsplus user,noauto,nls=koi8-r 0 0 /dev/cdrom /mnt/cdrom hfs user,noauto,iocharset=koi8-r,codepage=10007 0 0 Currently mount will stop at the first line and produce an error if the filesystem is not udf or iso (in the example). It will ignore the following lines. This would greatly improve handling of removable devices. Is there something (standards for example) which could prevent from this implementation? -- Kind regards, Pavel Fedin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] smbfs bug fix
Current smbfs has a bug: you can't supply "user, noauto" flags for it
in /etc/fstab. smbmount tool expands this to "noexec, nosuid, nodev,
user, noauto" and smbfs rejects all arguments because it doesn't know
any of these keywords.
This patch fixes it. It introduces these arguments to the smbfs which
will silently ignore them in the same way as cifs does.
The patch is made for 2.6.11.1 kernel.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
--- linux-2.6.11.1/fs/smbfs/inode.c.orig2005-03-04 12:26:29.0
-0500
+++ linux-2.6.11.1/fs/smbfs/inode.c 2005-03-15 11:57:52.0 -0500
@@ -351,6 +351,11 @@
{ "iocharset", 0, 'i' },
{ "codepage", 0, 'c' },
{ "ttl",0, 't' },
+ { "noexec", SMB_MOUNT_IGNORE, 1},
+ { "nosuid", SMB_MOUNT_IGNORE, 1},
+ { "nodev", SMB_MOUNT_IGNORE, 1},
+ { "user", SMB_MOUNT_IGNORE, 1},
+ { "noauto", SMB_MOUNT_IGNORE, 1},
{ NULL, 0, 0}
};
--- linux-2.6.11.1/include/linux/smb_mount.h.orig 2005-03-04
12:26:27.0 -0500
+++ linux-2.6.11.1/include/linux/smb_mount.h2005-03-15 11:38:28.0
-0500
@@ -42,6 +42,7 @@
#define SMB_MOUNT_GID 0x0040 /* Use user specified gid */
#define SMB_MOUNT_FMODE0x0080 /* Use user specified file mode
*/
#define SMB_MOUNT_DMODE0x0100 /* Use user specified dir mode
*/
+#define SMB_MOUNT_IGNORE 0x8000 /* Dummy flag */
struct smb_mount_data_kernel {
int version;
Generating NLS modules
Nobody answered so i repeat the question. I think i found a way to make use of NLS table for HFS filesystem and i'm going to try to implement it. But first i need to create NLS module for codepage 10007 (Mac cyrillic). In the beginning of every existing NLS module code i see comment which says that this file is automatically generated from data found at unicode.org. Could you tell me where i can find a convertor and what data it can use as input? I explored unicode.org and found some conversion data at oss.software.ibm.com/icu/. The data is available in UCM and XML formats. Are those files suitable? -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Floppy driver DMA question - PLEASE answer me, it's important for fixing
I'd like to ask some questions about floppy driver. I am owner of Pegasos-II PowerPC-based mainboard (http://www.pegasosppc.com) and floppy drive doesn't work on my machine. It doesn't read any data, sometimes even causes random crashes. Sometimes operation looks like completed ok but wrong data are read from/written to disk. Everything points to DMA problem - wrong region is used. I tried to turn off DMA by specifying floppy=nodma but then it doesn't work at all. I investigated the problem and discovered that virtual DMA for PowerPC is not implemented at all and hardware DMA is also handled differently. So here is my question: In include/asm-ppc/floppy.h i see the following: --- cut --- /* * The PowerPC has no problems with floppy DMA crossing 64k borders. */ #define CROSS_64KB(a,s) (0) --- cut --- What architectures was this tested on? Only Macintoshes or also something else? Does this work on CHRP-based machines? Pegasos is a CHRP-based machine and i'd like to know if ISA DMA is restricted in the same way as on x86. If yes, i will try to replace this macro with one taken from include/asm-i386/floppy.h but i'm afraid of reducing functionality or even breaking support for some machines which i don't know about. I guess i should use some #ifdef's here but i don't know conditions for them. P. S. For information: Pegasos uses Discovery II MV64361 as a northbridge and VIA 8231 as southbridge. For full technical specifications see: http://www.pegasosppc.com/tech_specs.php -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Non-DMA mode for floppy on PowerPC
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines. To use it: 1. Do not build floppy driver as a module, link it statically. Transferring parameters to it from insmod is still problematic, at least it doesn't work properly on my system. May be i'll clean it up in future. 2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify your drive type here using floppy=,,cmos. For example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my system. This patch does not affect operation of the driver in DMA mode so it's safe to use on any platform. -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] ppc_floppy-vdma.diff Description: Binary data
Re: [PATCH] Non-DMA mode for floppy on PowerPC
Sorry for the inconvenience, i missed kernel version number. The patch is written for 2.6.8 kernel. -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Non-DMA mode for floppy on PowerPC
Was posted with wrong content-type and i got no reply, so i decided to repost
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines.
To use it:
1. Do not build floppy driver as a module, link it statically. Transferring
parameters to it from insmod is still problematic, at least it doesn't work
properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify
your drive type here using floppy=,,cmos. For
example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my
system.
This patch does not affect operation of the driver in DMA mode so it's safe to
use on any platform.
The patch is written for kernel version 2.6.8.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
--- include/asm-ppc/floppy.h.orig 2004-08-14 09:36:45.0 +0400
+++ include/asm-ppc/floppy.h2005-02-12 02:26:54.0 +0300
@@ -11,30 +11,188 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port)outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma()disable_dma(FLOPPY_DMA)
-#define fd_request_dma()request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned
int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma()CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue()CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq()disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq()request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ register unsigned char st;
+
+#undef TRACE_FLPY_INT
+
+#ifdef TRACE_FLPY_INT
+ static int calls=0;
+ static int bytes=0;
+ static int dma_wait=0;
+#endif
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+#ifdef TRACE_FLPY_INT
+ if(!calls)
+ bytes = virtual_dma_count;
+#endif
+ {
+ register int lcount;
+ register char *lptr;
+
+ st = 1;
+ for(lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if(st != 0xa0)
+ break;
+ if(virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+#ifdef TRACE_FLPY_INT
+ calls++;
+#endif
+ if(st == 0x20)
+ return IRQ_HANDLED;
+ if(!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+#ifdef TRACE_FLPY_INT
+ printk("count=%x, residue=%x calls=%d bytes=%d dma_wait=%d\n",
+ virtual_dma_count, virtual_dma_residue, calls, bytes,
+ dma_wait);
+ calls = 0;
+ dma_wait=0;
+#endif
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+#ifdef TRACE_FLPY_INT
+ if(!virtual_dma_count)
+ dma_wait++;
+#endif
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+
[PATCH] Non-DMA mode for floppy on PowerPC
Nobody answered, repost again.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines.
To use it:
1. Do not build floppy driver as a module, link it statically. Transferring
parameters to it from insmod is still problematic, at least it doesn't work
properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify
your drive type here using floppy=,,cmos. For
example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my
system.
This patch does not affect operation of the driver in DMA mode so it's safe to
use on any platform.
The patch is written for kernel version 2.6.8. Please merge it with -p0
argument, i already know it's wrong and will be more correct in the future.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
--- include/asm-ppc/floppy.h.orig 2004-08-14 09:36:45.0 +0400
+++ include/asm-ppc/floppy.h2005-02-12 02:26:54.0 +0300
@@ -11,30 +11,188 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port)outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma()disable_dma(FLOPPY_DMA)
-#define fd_request_dma()request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned
int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma()CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue()CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq()disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq()request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ register unsigned char st;
+
+#undef TRACE_FLPY_INT
+
+#ifdef TRACE_FLPY_INT
+ static int calls=0;
+ static int bytes=0;
+ static int dma_wait=0;
+#endif
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+#ifdef TRACE_FLPY_INT
+ if(!calls)
+ bytes = virtual_dma_count;
+#endif
+ {
+ register int lcount;
+ register char *lptr;
+
+ st = 1;
+ for(lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if(st != 0xa0)
+ break;
+ if(virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+#ifdef TRACE_FLPY_INT
+ calls++;
+#endif
+ if(st == 0x20)
+ return IRQ_HANDLED;
+ if(!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+#ifdef TRACE_FLPY_INT
+ printk("count=%x, residue=%x calls=%d bytes=%d dma_wait=%d\n",
+ virtual_dma_count, virtual_dma_residue, calls, bytes,
+ dma_wait);
+ calls = 0;
+ dma_wait=0;
+#endif
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+#ifdef TRACE_FLPY_INT
+ if(!virtual_dma_count)
+ dma_wait++;
+#endif
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_
Re: [PATCH] Russian encoding support for MacHFS
On Tue, 25 Jan 2005 16:34:57 +0100 (CET)
Roman Zippel <[EMAIL PROTECTED]> wrote:
> I'm not quite sure, what problem you're trying to solve here.
I am trying to implement character sets conversion for MacHFS. I have some CD
s with russian file names. Currently they are not displayed properly because
Linux uses KOI8-R character set for russian letters and Macintosh uses its own
character set called Mac-cyrillic or codepage 10007.
Firstly i tried to implement character set conversion using NLS tables. It was
done using "iocharset" and "codepage" arguments. "Iocharset" specified Linux's
local character set and "codepage" specified HFS's character set. So to convert
a character i needed to process it twice: convert from "codepage" to Unicode
and then convert from Unicode to "iocharset".
The problem with this is that some characters will be lost during this
conversion. Not all characters from source ("codepage") charset are present in
destination ("iocharset") charset table (for example "Folder" sign). But for
proper operation of dir.c/hfs_lookup() function we need to be able to convert
the name back from KOI8-R to CP10007 otherwise searching algorythm will fail.
This will lead to that we won't be able to operate with any file which contains
such a characters.
A solution was to use my own conversion table which ensures that no characters
will be lost during conversion in both directions. Every unique source
character is translated to some unique destination character. Of course
Mac-specific characters are not displayed properly but they're not lost either.
"codepage" argument was omitted for simplicity because specific "iocharset"
implies specific "codepage" (for example if iocharset is koi8-r then we can
assume that Macintosh codepage is mac-cyrillic). But some people said that this
patch can't be approved because not using NLS is bad solution. So i'd like to
talk to you, may be we'll find a better solution (because you know HFS better
than me) or we can come to a conclusion that there is really no solution and
push the patch upstream.
> If you want to store unicode characters use HFS+, I plan to implement nls
> support real soon for it (especially because to also fix the missing
> decomposition support).
Would be nice. I also thought about it but i have no HFS+ disks with russian
names so i can't test it. And i decided not to do a "blind" implementation in
order not to break the filesystem. Currently my patch adds "iocharset"
argumnent to HFS+ also (so that i can specify both filesystems in one
/etc/fstab line, this is useful for CD-ROM) but it is ignored there.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Generating NLS modules
Nobody answered so i repeat the question. I think i found a way to make use of NLS table for HFS filesystem and i'm going to try to implement it. But first i need to create NLS module for codepage 10007 (Mac cyrillic). In the beginning of every existing NLS module code i see comment which says that this file is automatically generated from data found at unicode.org. Could you tell me where i can find a convertor and what data it can use as unput? I explored unicode.org and found some conversion data at oss.software.ibm.com/icu/. The data is available in UCM and XML formats. Are those files suitable? -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Non-DMA mode for floppy on PowerPC, new version
Here is a cleaned up version of my 2.6.8 kernel patch.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC and
AmigaOne machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring
parameters to it from insmod is still problematic, at least it doesn't work
properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify
your drive type here using floppy=,,cmos. For
example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my
system. Default drive type is 2.88 mb.
This patch does not affect operation of the driver in DMA mode so it's safe to
use on any platform.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
--- linux-2.6.8.1-10mdk/include/asm-ppc/floppy.h.orig 2004-08-14
06:55:10.0 -0400
+++ linux-2.6.8.1-10mdk/include/asm-ppc/floppy.h2005-02-24
09:41:54.594830800 -0500
@@ -11,30 +11,163 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port)outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma()disable_dma(FLOPPY_DMA)
-#define fd_request_dma()request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned
int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma()CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue()CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq()disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq()request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ unsigned char st;
+
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+ {
+ int lcount;
+ char *lptr;
+
+ st = 1;
+ for (lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if (st != 0xa0)
+ break;
+ if (virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+ if (st == 0x20)
+ return IRQ_HANDLED;
+ if (!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const char * device_id)
+{
+ return 0;
+}
+
+static void vdma_nop(unsigned int dummy)
+{
+}
+
+
+static int vdma_get_dma_residue(unsigned int dummy)
+{
+ return virtual_dma_count + virtual_dma_residue;
+}
+
+
+static int fd_request_irq(void)
+{
+ if (can_use_virtual_dma)
+ return request_irq(FLOPPY_IRQ, floppy_hardint,SA_INTERRUPT,
+ "floppy", NULL);
+ else
+ return request_irq(FLOPPY_IRQ, floppy_interrupt,
+
SA_INTERRUPT|S
[PATCH] Russian encoding support for MacHFS
Hello, guys! I'd like to present to the community my second kernel project.
This patch adds support for russian characters on MacHFS volumes if you use
koi8-r encoding on Linux (this is the common case in Russia).
The implementation is probably not very good because it uses its own tables
instead of NLS modules. Using NLS modules i consider impossible because due to
MacHFS nature (at least current implementation nature) names must be supplied
in MacOS encoding for proper searching. This means that you must to be able to
reverse-translate all names from Linux encoding to Mac encoding. Using NLS
causes characters loss if requested character does not exist in the table (it
is substituted by '?'). Macintosh disks often contains specific characters in
file names ("Folder" character for example) which will be lost in this case.
If someone has some idea how to fix this you're welcome. I currently don't see
a way to make the thing better because i don't know internal HFS structure.
Probably using utf8 as host encoding would solve the problem but it's not
commonly used in Russia.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
hfs-koi8r.diff.bz2
Description: BZip2 compressed data
Re: [PATCH] Russian encoding support for MacHFS
On Mon, 24 Jan 2005 19:46:18 +0100 Alex Riesen <[EMAIL PROTECTED]> wrote: > how about just leave the characters unchanged? (remap them to the same > codes in Unicode). But what to do when i convert then from unicode to 8-bit iocharset? This can lead to that several characters in Mac charset will be converted to the same character in Linux charset. This will lead to information loss and name will not be reverse-translatable. To describe the thing better: i have 8-bit Mac encoding and 8-bit target encoding (iocharset). I need to convert from (1) to (2) and be able to convert back. I tried to perform a one-way conversion like in other filesystems but this didn't work. Probably NLS tables can be used when iocharset is UTF8. If you wish i can try to implement it after some time. > Unicode, and its encoding UTF8 IS commonly used everywhere. > And Russia can (and often does) use it just as well. Many people say many software is not UTF8-ready yet. Anyway i had problems when tried to use it. Many russian ASCII documents use 8-bit encoding so i need to be able to deal with them. Many software assumes that 1 byte is 1 character. > P.S. Read Documentation/SubmittingPatches. Ok. Sorry for violations. > What kernel is the patch against? 2.6.8. -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Generating NLS modules
One more question about NLS modules. In the beginning of every module code i see comment which says that this file is automatically generated from data found at unicode.org. Where can i find a convertor and what data can it use as unput? I explored unicode.org and found some conversion data at oss.software.ibm.com/icu/. The data is available in UCM and XML formats. Are those files suitable? -- Best regards, Pavel Fedin, mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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/7] Add support for Exynos SROM Controller driver
Hello! > This patch set adds support for Exynos SROM controller DT based driver. > Currently SROM register sets are used only during S2R, so driver > basically added for taking care of S2R. It will help us in removing > static mapping from exynos.c and other extra code handline during S2R. Very good news, but, your driver seems not to do anything except suspend/resume. But how do i add some device plugged into it? In order to be operational, its outputs have to be configured. But how do i do it with your driver? For example, on SMDK boards SROM controller is used to connect SMSC9111 etherner chip. Currently i use hardcoded initialization based on of_machine_is_compatible(), but i believe this would be considered a hack and such a thing cannot be pushed upstream. I guess i have to put all needed configuration into device tree somehow. But how? Are there any recommentations? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/7] Add support for Exynos SROM Controller driver
Hello! > That is interesting. What do you mean by that? Although SROM controller > can access external memory (SRAM, ROM) but it is not exactly a bus. How > is the SMSC9111 "connected"? What interface or protocol is used? SROM controller actually provides a demultiplexed external address and data bus. This way you could hook up old good ROM chip to it (hence its name). However, you can plug in there anything else with the appropriate interface, and SMSC9111 uses exactly that. Just some address + control + data wires. Therefore, you can think of SROMc as a simple bus. > I am sorry but I cannot figure out what exactly are you talking about. > The Device Tree is the glue to describe the board, the hardware and its > configuration. Please elaborate a little more. Yes, exactly that. SROM controller has 4 outputs, and for every of these outputs you have to choose mode and timings. Once you set them correctly, you can use peripherial behind them. These timings actually depend on the actual peripherial. By this time i remembered that u-boot guys also did something with this. And here are links: http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/exynos5250-smdk5250.dts;h=8b695442b1a29dec4e3 53ebd3cfee0ff89f218a6;hb=HEAD#l43 - this is how connection is described http://git.denx.de/?p=u-boot.git;a=blob;f=board/samsung/common/board.c;h=d32c75de50858f131284e28db0c 7ed55883f1cb0;hb=HEAD#l184 - and this is parsing code There's only one small problem with their code. "bank" parameter is device-wide, therefore you cannot configure more than one bank. For SMDK boards it's OK, but in future you may run into problem with this. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 6/8] drivers: soc: add support for exynos SROM driver
Hello! > can we add the "depends on ... && PM" now, later, once > you'll extend it, you remove it again? Yes, you can. However, i think i'll post my patches as soon as the code gets integrated into some repository, before it even goes to the RC. So, it's up to you. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 6/8] drivers: soc: add support for exynos SROM driver
Hello! > AFAIR Fedin was talking about missing functionality, not about adding > the contribution by himself. So he might add it or he might not. I did > not receive any commitments from him. I am waiting for the driver to be integrated, because i see it's constantly redesigned. Then i'll post my patches. By the way, they will be useful only if pin controller driver for 5410 is accepted upstream, several authors have done it but i still didn't see it in upstream. Pin controller is needed in order to configure multi-functional pins correctly. > The driver should be "proper" for > the time being (which could mean !PM dependency). If there is a need, > then the dependency will be removed. I can do it later if you prefer. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 6/8] drivers: soc: add support for exynos SROM driver
Hello! > > Pin controller is needed in order to configure multi-functional pins > > correctly. > > Are there any obstacles for upstreaming it? I don't know. The last post on this topic is from March, 2015: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html. Patch 0003 has been acked-by, and nothing more since that. Actually, only 0002 and 0003 of this series are needed for the pin controller. 0001 has been accepted (27284129522e7e2a5b89e80bd44ea3345f79c9e8). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 0/8] Add support for Exynos SROM Controller driver
Hello! > > This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for > > boot > > and S2R functionality. > > > > Entire patchset tested on Trats2 (Exynos4412) board. Unless Kukjin picks > it also, I plan to take it for v4.5. Tested on SMDK5410. By the way, what is current status? If this is final revision, can i post my Ethernet support patchset on top of it? Tested-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 0/8] Add support for Exynos SROM Controller driver
Hello! > Applied, this whole series. Where can i find the recent code to base my series on? I looked at linux-samsung.git but was unable to find it there. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 0/8] Add support for Exynos SROM Controller driver
Hello! > You may need to fetch again? > Anyway the branch is v4.4-next/driver-samsung or tags/samsung-driver... > Or just for-next should be fine I think. Thank you very much, already found it, and even posted my series, you should have already seen it. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/
NinjaSCSI PCMCIA card
Hello! Can i get this card working? Hotplug doesn't recognise it, however i know that Linux supports it. My kernel is relatively new (2.6.11.1). cartctl info gives this: --- cut --- PRODID_1="" PRODID_2="NinjaSCSI Card_" PRODID_3="Ver 1.00" PRODID_4="NS00100M" MANFID=, FUNCID=255 --- cut --- I wonder why the hell does it have empty numeric IDs? -- Best regards, Pavel mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PING: [PATCH] Avoid conflict with host definitions when cross-compiling
PING! 2 Yaakov: Hello! I remember you upstreamed this one: https://cygwin.com/ml/cygwin/2012-06/msg00221/0002-tools-include-use-stdint-types-for-user -space-bytesh.patch Who is the person to cc: ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On > Behalf Of Pavel Fedin > Sent: Wednesday, June 03, 2015 11:25 AM > To: linux-kernel@vger.kernel.org > Subject: [PATCH] Avoid conflict with host definitions when cross-compiling > > Certain platforms (e. g. BSD-based ones) define some ELF constants according > to host. > This patch fixes problems with cross-building Linux kernel on these platforms. > > Signed-off-by: Pavel Fedin > --- > scripts/mod/modpost.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h > index 168b43d..9f51365 100644 > --- a/scripts/mod/modpost.h > +++ b/scripts/mod/modpost.h > @@ -11,6 +11,12 @@ > > #include "elfconfig.h" > > +/* Cygwin's elf.h defines these according to host's word size */ > +#undef ELF_ST_BIND > +#undef ELF_ST_TYPE > +#undef ELF_R_SYM > +#undef ELF_R_TYPE > + > #if KERNEL_ELFCLASS == ELFCLASS32 > > #define Elf_EhdrElf32_Ehdr > -- > 1.9.5.msysgit.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/ -- 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/
PING 2: [PATCH] Avoid conflict with host definitions when cross-compiling
Hello! Guys, i've seen you reviewing some cross-compiling related changes by Paul Gortmaker. Can anybody help me with upstreaming this small thing? I don't know who to cc:, and definitely not Linus. LKML is vast, and the small patch seems to be lost. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of > Pavel Fedin > Sent: Wednesday, June 03, 2015 11:25 AM > To: linux-kernel@vger.kernel.org > Subject: [PATCH] Avoid conflict with host definitions when cross-compiling > > Certain platforms (e. g. BSD-based ones) define some ELF constants according > to host. > This patch fixes problems with cross-building Linux kernel on these platforms. > > Signed-off-by: Pavel Fedin > --- > scripts/mod/modpost.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h > index 168b43d..9f51365 100644 > --- a/scripts/mod/modpost.h > +++ b/scripts/mod/modpost.h > @@ -11,6 +11,12 @@ > > #include "elfconfig.h" > > +/* Cygwin's elf.h defines these according to host's word size */ > +#undef ELF_ST_BIND > +#undef ELF_ST_TYPE > +#undef ELF_R_SYM > +#undef ELF_R_TYPE > + > #if KERNEL_ELFCLASS == ELFCLASS32 > > #define Elf_EhdrElf32_Ehdr > -- > 1.9.5.msysgit.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/ -- 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] Avoid conflict with host definitions when cross-compiling
Certain platforms (e. g. BSD-based ones) define some ELF constants according to host. This patch fixes problems with cross-building Linux kernel on these platforms. Signed-off-by: Pavel Fedin --- scripts/mod/modpost.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h index 168b43d..9f51365 100644 --- a/scripts/mod/modpost.h +++ b/scripts/mod/modpost.h @@ -11,6 +11,12 @@ #include "elfconfig.h" +/* Cygwin's elf.h defines these according to host's word size */ +#undef ELF_ST_BIND +#undef ELF_ST_TYPE +#undef ELF_R_SYM +#undef ELF_R_TYPE + #if KERNEL_ELFCLASS == ELFCLASS32 #define Elf_EhdrElf32_Ehdr -- 1.9.5.msysgit.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/
RE: [PATCH v3 0/7] KVM: arm/arm64: gsi routing support
Tested-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: Eric Auger [mailto:eric.au...@linaro.org] > Sent: Monday, August 03, 2015 6:31 PM > To: eric.au...@st.com; eric.au...@linaro.org; > linux-arm-ker...@lists.infradead.org; > kvm...@lists.cs.columbia.edu; k...@vger.kernel.org; > christoffer.d...@linaro.org; > marc.zyng...@arm.com > Cc: linux-kernel@vger.kernel.org; patc...@linaro.org; pbonz...@redhat.com; > andre.przyw...@arm.com; p.fe...@samsung.com > Subject: [PATCH v3 0/7] KVM: arm/arm64: gsi routing support > > With the advent of GICv3 ITS in-kernel emulation, KVM GSI routing > appears to be requested. More specifically MSI routing is needed. > irqchip routing does not sound to be really useful on arm but usage of > MSI routing also mandates to integrate irqchip routing. The initial > implementation of irqfd on arm must be upgraded with the integration > of kvm irqchip.c code and the implementation of its standard hooks > in the architecture specific part. > > In case KVM_SET_GSI_ROUTING ioctl is not called, a default routing > table with flat irqchip routing entries is built enabling to inject gsi > corresponding to the SPI indexes seen by the guest. > > As soon as KVM_SET_GSI_ROUTING is called, user-space overwrites this > default routing table and is responsible for building the whole routing > table. > > for arm/arm64 KVM_SET_GSI_ROUTING has a limited support: > - only applies to KVM_IRQFD and not to KVM_IRQ_LINE > > - irqchip routing was tested on Calxeda midway (VFIO with irqfd) > with and without explicit routing > - MSI routing without GICv3 ITS was tested using APM Xgene-I > (qemu VIRTIO-PCI vhost-net without gsi_direct_mapping). > - MSI routing with GICv3 ITS is *NOT* tested. > > Code can be found at https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.2-rc4- > gsi-routing-v3 > > It applies on Andre's [PATCH v2 00/15] KVM: arm64: GICv3 ITS emulation > (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355727.html) > > History: > v2 -> v3: > - eventually got rid of KVM_IRQ_ROUTING_EXTENDED_MSI new type at user > api level and use KVM_MSI_VALID_DEVID flag instead > - remove usage of KVM_IRQ_ROUTING_EXTENDED_MSI type at kernel level too. > - propagate user flags downto the kernel to make sure the userspace > correctly set devid in GICv3 ITS case (still under discussion) > > v1 -> v2: > - user API changed: > x devid id passed in kvm_irq_routing_msi > x kept the new routing entry type: KVM_IRQ_ROUTING_EXTENDED_MSI > - kvm_host.h: adopt Andre's proposal to replace the msi_msg by a struct > composed of the msi_msg and devid in kvm_kernel_irq_routing_entry > - Fix bug reported by Pavel: Added KVM_IRQ_ROUTING_EXTENDED_MSI handling > in eventfd.c > - added vgic_v2m_inject_msi in vgic-v2-emul.c as suggested by Andre > - fix bug reported by Andre: bad setting of msi.flags and msi.devid > in kvm_send_userspace_msi > - avoid injecting reserved IRQ numbers in vgic_irqfd_set_irq > > RFC -> PATCH: > - clearly state limited support on arm/arm64: > KVM_IRQ_LINE not impacted by GSI routing > - add default routing table feature (new patch file) > - changed uapi to use padding field area > - reword api.txt > > Eric Auger (7): > KVM: api: pass the devid in the msi routing entry > KVM: kvm_host: add devid in kvm_kernel_irq_routing_entry > KVM: irqchip: convey devid to kvm_set_msi > KVM: arm/arm64: enable irqchip routing > KVM: arm/arm64: build a default routing table > KVM: arm/arm64: enable MSI routing > KVM: arm: enable KVM_SIGNAL_MSI and MSI routing > > Documentation/virtual/kvm/api.txt | 35 ++--- > arch/arm/include/asm/kvm_host.h | 2 + > arch/arm/kvm/Kconfig | 3 ++ > arch/arm/kvm/Makefile | 2 +- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/Kconfig| 2 + > arch/arm64/kvm/Makefile | 2 +- > include/kvm/arm_vgic.h| 2 - > include/linux/kvm_host.h | 8 ++- > include/uapi/linux/kvm.h | 5 +- > virt/kvm/arm/vgic-v2-emul.c | 16 ++ > virt/kvm/arm/vgic.c | 107 > ++ > virt/kvm/irqchip.c| 8 ++- > 13 files changed, 158 insertions(+), 35 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/
RE: [PATCH 2/5] gic-its: Allow pci_requester_id to be overridden.
Hello! > > What if instead of this function we simply add a field to a struct > > pci_bus ? Then bus driver would > > fill in HW-specific ID bits for every bus. > > I can send a patch if interested. > > There is a lot of work being done in the upstream to extract the proper > information from the device tree. We are going to piggyback on that for > the next versions of the patch. Where can i take a look at the code? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 2/5] gic-its: Allow pci_requester_id to be overridden.
Hello!
> -Original Message-
> From: linux-pci-ow...@vger.kernel.org
> [mailto:linux-pci-ow...@vger.kernel.org] On Behalf Of David
> Daney
> Sent: Wednesday, July 15, 2015 7:55 PM
> To: linux-arm-ker...@lists.infradead.org; Catalin Marinas; Will Deacon; Bjorn
> Helgaas; linux-
> p...@vger.kernel.org; Thomas Gleixner; Jason Cooper
> Cc: linux-kernel@vger.kernel.org; Robert Richter; David Daney
> Subject: [PATCH 2/5] gic-its: Allow pci_requester_id to be overridden.
>
> From: David Daney
>
> Signed-off-by: David Daney
> ---
> drivers/irqchip/irq-gic-v3-its.c | 14 +-
> include/linux/irqchip/arm-gic-v3.h | 2 ++
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 1b7e155..4580970 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1189,11 +1189,23 @@ static int its_pci_msi_vec_count(struct pci_dev *pdev)
> return max(msi, msix);
> }
>
> +static u32 its_dflt_pci_requester_id(struct pci_dev *pdev, u16 alias)
> +{
> + return alias;
> +}
> +
> +static its_pci_requester_id_t its_pci_requester_id =
> its_dflt_pci_requester_id;
> +void set_its_pci_requester_id(its_pci_requester_id_t fn)
> +{
> + its_pci_requester_id = fn;
> +}
> +EXPORT_SYMBOL(set_its_pci_requester_id);
IMHO having a globally defined function is a horrible approach. What if some
HW has two different
PCI host controllers, each of them wants to provide different form of IDs? I
know, this is just
imaginary, but still...
What if instead of this function we simply add a field to a struct pci_bus ?
Then bus driver would
fill in HW-specific ID bits for every bus.
I can send a patch if interested.
> +
> static int its_get_pci_alias(struct pci_dev *pdev, u16 alias, void *data)
> {
> struct its_pci_alias *dev_alias = data;
>
> - dev_alias->dev_id = alias;
> + dev_alias->dev_id = its_pci_requester_id(pdev, alias);
> if (pdev != dev_alias->pdev)
> dev_alias->count += its_pci_msi_vec_count(dev_alias->pdev);
>
> diff --git a/include/linux/irqchip/arm-gic-v3.h
> b/include/linux/irqchip/arm-gic-v3.h
> index ffbc034..18e3757 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -389,6 +389,8 @@ int its_cpu_init(void);
> int its_init(struct device_node *node, struct rdists *rdists,
>struct irq_domain *domain);
>
> +typedef u32 (*its_pci_requester_id_t)(struct pci_dev *, u16);
> +void set_its_pci_requester_id(its_pci_requester_id_t fn);
> #endif
>
> #endif
> --
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello! > >> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in > >> > the > >> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, > >> > Tacs. > >> > +Each value is specified in cycles and has the > >> > following > >> > +meaning and valid range: > >> > +Tacp : Page mode access cycle at Page mode (0 - > >> > 15) > >> > +Tcah : Address holding time after CSn (0 - 15) > >> > +Tcoh : Chip selection hold on OEn (0 - 15) > >> > +Tacc : Access cycle (0 - 31, the actual time is > >> > N + 1) > >> > +Tcos : Chip selection set-up before OEn (0 - 15) > >> > +Tacs : Address set-up before CSn (0 - 15) > >> > >> This is not easily extended. Perhaps a property per value instead. > > > > We had a discussion with Krzysztof about it, he agreed with this form of > > the property. > > My concern was that it's just too much typing, and makes little sense > > because these > > settings always go together. If register layout changes, or parameter set > > changes in > > incompatible way, then it's another device, not exynos-srom anymore. > > So would you agree with that, or is your position strong? > > I'm thinking for a new version of the controller which could add (or > remove) new timing parameters, but then I guess you can interpret the > field differently based on the compatible string. Anyway, your problem > to deal with. Of course, my thought is that if compatible string is different, then it's already a different device. And of course it would have different parameters. So, OK, i'll post new version with fixed documentation today. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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: PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello! > >> If you think I should reconsider the patch, you should resubmit it. > > > > I understand this, of course. But, before doing this i'd like to > > clarify your concern, why exactly you think that loopback test will > > break. > > If I didn't reply it means I don't have anything constructive to say > to you, and probably I'll end up agreeing with your analysis of the > loopback test issue. > > I'm not going to ask more than one more time for you to repost your > patch. But, in this case, i don't have anything to change, do i? Or is it just a formal requirement to RESEND? I can do this, if you want to. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 v8 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.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/
[PATCH v8 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.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/
[PATCH v8 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", &width))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.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/
[PATCH v8 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.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/
[PATCH v8 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..07c8507 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.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/
[PATCH RESEND] net: smsc911x: Reset PHY during initialization
On certain hardware after software reboot the chip may get stuck and fail
to reinitialize during reset. This can be fixed by ensuring that PHY is
reset too.
Old PHY resetting method required operational MDIO interface, therefore
the chip should have been already set up. In order to be able to function
during probe, it is changed to use PMT_CTRL register.
The problem could be observed on SMDK5410 board.
Signed-off-by: Pavel Fedin
---
drivers/net/ethernet/smsc/smsc911x.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index c860c90..219a99b 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -809,22 +809,17 @@ static int smsc911x_phy_check_loopbackpkt(struct
smsc911x_data *pdata)
static int smsc911x_phy_reset(struct smsc911x_data *pdata)
{
- struct phy_device *phy_dev = pdata->phy_dev;
unsigned int temp;
unsigned int i = 10;
- BUG_ON(!phy_dev);
- BUG_ON(!phy_dev->bus);
-
- SMSC_TRACE(pdata, hw, "Performing PHY BCR Reset");
- smsc911x_mii_write(phy_dev->bus, phy_dev->addr, MII_BMCR, BMCR_RESET);
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ smsc911x_reg_write(pdata, PMT_CTRL, temp | PMT_CTRL_PHY_RST_);
do {
msleep(1);
- temp = smsc911x_mii_read(phy_dev->bus, phy_dev->addr,
- MII_BMCR);
- } while ((i--) && (temp & BMCR_RESET));
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ } while ((i--) && (temp & PMT_CTRL_PHY_RST_));
- if (temp & BMCR_RESET) {
+ if (unlikely(temp & PMT_CTRL_PHY_RST_)) {
SMSC_WARN(pdata, hw, "PHY reset failed to complete");
return -EIO;
}
@@ -2296,7 +2291,7 @@ static int smsc911x_init(struct net_device *dev)
}
/* Reset the LAN911x */
- if (smsc911x_soft_reset(pdata))
+ if (smsc911x_phy_reset(pdata) || smsc911x_soft_reset(pdata))
return -ENODEV;
dev->flags |= IFF_MULTICAST;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 0/2] net: thunderx: Miscellaneous cleanups
Tested-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Monday, December 07, 2015 8:01 AM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p.fe...@samsung.com; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 0/2] net: thunderx: Miscellaneous cleanups > > From: Sunil Goutham > > This patch series contains contains couple of cleanup patches. > > Sunil Goutham (1): > net, thunderx: Remove unnecessary rcv buffer start address management > > Yury Norov (1): > net: thunderx: nicvf_queues: nivc_*_intr: remove duplication > > drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 189 > +--- > drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 10 +- > 2 files changed, 51 insertions(+), 148 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello!
> 4. This branch is not pushed to linux-next. I will sort it out if my
> previous pull requests get in. I will be out of office for Christmas so
> depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
> not go into v4.5 (yay...).
>
> 5. If it does not get into v4.5, I will rebase it and proceed further
> for v4.6.
>
> If you have any questions, please let me know.
Thank you very much. No, i don't have any questions, i'm glad that my work is
picked up and not lost, i'm just keeping an eye on it
until it goes to stable.
P.S. Not related to these sets directly, just to note... When i was writing
the doc for SROMc bindings, i noticed that we have two
directories for Exynos in Documentation/devicetree/bindings/arm:
1. Documentation/devicetree/bindings/arm/exynos
2. Documentation/devicetree/bindings/arm/Samsung
In (1) we have only a single old file, shouldn't this be cleaned up and
shouldn't this file be moved to (2)?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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/6] net: thunderx: Increase transmit queue length
Hello! This one breaks networking on my machine: --- cut --- swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 Hardware name: Cavium ThunderX CN88XX board (DT) Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x14/0x1c [] dump_stack+0x88/0xc8 [] swiotlb_alloc_coherent+0x150/0x168 [] __dma_alloc+0x58/0x1e8 [] nicvf_alloc_q_desc_mem.isra.14+0xc0/0xdc [] nicvf_config_data_transfer+0x448/0x728 [] nicvf_open+0x184/0x994 [] __dev_open+0xb4/0x120 [] __dev_change_flags+0x8c/0x150 [] dev_change_flags+0x20/0x5c [] do_setlink+0x27c/0x8e0 [] rtnl_newlink+0x4b4/0x6c4 [] rtnetlink_rcv_msg+0x90/0x22c [] netlink_rcv_skb+0xd8/0x100 [] rtnetlink_rcv+0x30/0x40 [] netlink_unicast+0x158/0x1f8 [] netlink_sendmsg+0x324/0x380 [] sock_sendmsg+0x18/0x58 [] ___sys_sendmsg+0x254/0x264 [] __sys_sendmsg+0x40/0x84 [] SyS_sendmsg+0x10/0x20 thunder-nicvf 0002:01:08.4 enP2p1s8f4: Failed to alloc/config VF's QSet resources --- cut --- And none of interfaces work after this. Reverting this patch helps. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Tuesday, December 01, 2015 12:14 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 3/6] net: thunderx: Increase transmit queue length > > From: Sunil Goutham > > Under high transmit rates and with TSO enabled observing fluctuations > in TX performance. Seen especially with iperf3 application. > > Since TSO is taken care at driver level, with 64KB of TSO packets > and when window size is also high the rate at which CPU fills in > transmit descriptors is much higher than what HW is able to process. > Each 64KB TSO packet occupies gets segmented to ~43 1500 byte MTU packets > and occupies ~130 descriptors. Hence increasing transmit queue size. > > Signed-off-by: Sunil Goutham > --- > drivers/net/ethernet/cavium/thunder/nicvf_queues.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > index fb4957d..b1e93a9 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > @@ -62,7 +62,7 @@ > #define SND_QUEUE_CNT8 > #define CMP_QUEUE_CNT8 /* Max of RCV and SND qcount */ > > -#define SND_QSIZESND_QUEUE_SIZE2 > +#define SND_QSIZESND_QUEUE_SIZE3 > #define SND_QUEUE_LEN(1ULL << (SND_QSIZE + 10)) > #define MAX_SND_QUEUE_LEN(1ULL << (SND_QUEUE_SIZE6 + 10)) > #define SND_QUEUE_THRESH 2ULL > @@ -73,7 +73,7 @@ > /* Keep CQ and SQ sizes same, if timestamping > * is enabled this equation will change. > */ > -#define CMP_QSIZECMP_QUEUE_SIZE2 > +#define CMP_QSIZECMP_QUEUE_SIZE3 > #define CMP_QUEUE_LEN(1ULL << (CMP_QSIZE + 10)) > #define CMP_QUEUE_CQE_THRESH 0 > #define CMP_QUEUE_TIMER_THRESH 220 /* 10usec */ > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/6] net: thunderx: Switchon carrier only upon interface link up
Hello!
This one causes the network to stop working on Fedora 21. Probably has to do
with NetworkManager, which sees something unexpected.
IP address is never set up and connection is never activated, despite it has UP
flag.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Sunil
> Goutham
> Sent: Tuesday, December 01, 2015 12:14 PM
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sunil.gout...@caviumnetworks.com; Sunil Goutham
> Subject: [PATCH 5/6] net: thunderx: Switchon carrier only upon interface link
> up
>
> From: Sunil Goutham
>
> Call netif_carrier_on() only if interface's link is up. Switching this on
> upon IFF_UP by default, is causing issues with ethernet channel bonding
> in LACP mode. Initial NETDEV_CHANGE notification was being skipped.
>
> Also fixed some issues with link/speed/duplex reporting via ethtool.
>
> Signed-off-by: Sunil Goutham
> ---
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 16 +++-
> drivers/net/ethernet/cavium/thunder/nicvf_main.c |4 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c |2 ++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> index af54c10..a12b2e3 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> @@ -112,6 +112,13 @@ static int nicvf_get_settings(struct net_device *netdev,
>
> cmd->supported = 0;
> cmd->transceiver = XCVR_EXTERNAL;
> +
> + if (!nic->link_up) {
> + cmd->duplex = DUPLEX_UNKNOWN;
> + ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
> + return 0;
> + }
> +
> if (nic->speed <= 1000) {
> cmd->port = PORT_MII;
> cmd->autoneg = AUTONEG_ENABLE;
> @@ -125,6 +132,13 @@ static int nicvf_get_settings(struct net_device *netdev,
> return 0;
> }
>
> +static u32 nicvf_get_link(struct net_device *netdev)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> +
> + return nic->link_up;
> +}
> +
> static void nicvf_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> @@ -660,7 +674,7 @@ static int nicvf_set_channels(struct net_device *dev,
>
> static const struct ethtool_ops nicvf_ethtool_ops = {
> .get_settings = nicvf_get_settings,
> - .get_link = ethtool_op_get_link,
> + .get_link = nicvf_get_link,
> .get_drvinfo= nicvf_get_drvinfo,
> .get_msglevel = nicvf_get_msglevel,
> .set_msglevel = nicvf_set_msglevel,
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 7f709cb..dde8dc7 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1057,6 +1057,7 @@ int nicvf_stop(struct net_device *netdev)
>
> netif_carrier_off(netdev);
> netif_tx_stop_all_queues(nic->netdev);
> + nic->link_up = false;
>
> /* Teardown secondary qsets first */
> if (!nic->sqs_mode) {
> @@ -1211,9 +1212,6 @@ int nicvf_open(struct net_device *netdev)
> nic->drv_stats.txq_stop = 0;
> nic->drv_stats.txq_wake = 0;
>
> - netif_carrier_on(netdev);
> - netif_tx_start_all_queues(netdev);
> -
> return 0;
> cleanup:
> nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 2076ac3..d9f27ad 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -612,6 +612,8 @@ static void bgx_poll_for_link(struct work_struct *work)
> lmac->last_duplex = 1;
> } else {
> lmac->link_up = 0;
> + lmac->last_speed = SPEED_UNKNOWN;
> + lmac->last_duplex = DUPLEX_UNKNOWN;
> }
>
> if (lmac->last_link != lmac->link_up) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/6] net: thunderx: Increase transmit queue length
Hello! > > swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 > > CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 > > Hardware name: Cavium ThunderX CN88XX > > Are you sure 4.2.6 kernel is suitable for backporting this patch aimed > for linux-4.5 ? Why not? It's just a networking driver. And, i also have the same problem on 4.3 running as KVM guest with VFIO. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/6] net: thunderx: Increase transmit queue length
Hello! > Probably you might have to set "coherent_pool" size in bootargs to a > higher value. > Can you please check. I have tried to do this. I was able to enlarge the pool up to 4MB, and still got allocation failures. At 8MB pool preallocation stops working: --- cut --- Call trace: [] __alloc_pages_nodemask+0x4f4/0x7d4 [] atomic_pool_init+0x60/0x1a4 [] arm64_dma_init+0x20/0x28 [] do_one_initcall+0x8c/0x1a4 [] kernel_init_freeable+0x154/0x1f4 [] kernel_init+0x10/0xd8 DMA: failed to allocate 8192 KiB pool for atomic coherent allocation --- cut --- and i get even worse faults in the driver. I know that it is possible to allocate larger pools by setting CONFIG_FORCE_MAX_ZONEORDER, but: a) This is done on per-platform basis. For ThunderX we used to have a patch (http://www.spinics.net/lists/arm-kernel/msg415457.html), which never made it upstream, because vGIC fixes stopped requiring it at some point. And also we may want to use the nicvf driver not only on actual hardware, but also inside virtual machine in KVM. So do we need to set CONFIG_FORCE_MAX_ZONEORDER for virt too? And what if at some point qemu emulates not only "virt", but some other machine (let's say AMD X-Gene), and we run it on ThunderX and want to use nicvf with this model? b) IMHO it's not good to have a driver which simply does not work without some obscure option in boot arguments. So, i see several possible ways to solve this: 1. Introduce some mechanism which would allow the driver to tell the kernel that it needs coherent pool of large size. Can be problematic because the driver can be a module, and pool allocation happens early. 2. Can we use some other method for allocating queues, which would not require such a huge coherent pool? 3. The driver could check value of atomic_pool_size and adjust own memory requirements accordingly. This indeed looks like a quick hack, but would at least make things running quickly. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/6] net: thunderx: Increase transmit queue length
Hello! > > Probably you might have to set "coherent_pool" size in bootargs to a > > higher value. > > Can you please check. > > I have tried to do this. I was able to enlarge the pool up to 4MB, and still > got allocation > failures. At 8MB pool preallocation stops working: > --- cut --- > Call trace: > [] __alloc_pages_nodemask+0x4f4/0x7d4 > [] atomic_pool_init+0x60/0x1a4 > [] arm64_dma_init+0x20/0x28 > [] do_one_initcall+0x8c/0x1a4 > [] kernel_init_freeable+0x154/0x1f4 > [] kernel_init+0x10/0xd8 > DMA: failed to allocate 8192 KiB pool for atomic coherent allocation > --- cut --- > and i get even worse faults in the driver. > > I know that it is possible to allocate larger pools by setting > CONFIG_FORCE_MAX_ZONEORDER, > but: > a) This is done on per-platform basis. For ThunderX we used to have a patch > (http://www.spinics.net/lists/arm-kernel/msg415457.html), which never made it > upstream, > because vGIC fixes stopped requiring it at some point. And also we may want > to use the nicvf > driver not only on actual hardware, but also inside virtual machine in KVM. > So do we need to > set CONFIG_FORCE_MAX_ZONEORDER for virt too? And what if at some point qemu > emulates not only > "virt", but some other machine (let's say AMD X-Gene), and we run it on > ThunderX and want to > use nicvf with this model? > b) IMHO it's not good to have a driver which simply does not work without > some obscure option > in boot arguments. > > So, i see several possible ways to solve this: > > 1. Introduce some mechanism which would allow the driver to tell the kernel > that it needs > coherent pool of large size. Can be problematic because the driver can be a > module, and pool > allocation happens early. > 2. Can we use some other method for allocating queues, which would not > require such a huge > coherent pool? > 3. The driver could check value of atomic_pool_size and adjust own memory > requirements > accordingly. This indeed looks like a quick hack, but would at least make > things running > quickly. I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess it was a leftover from old defconfig, because i carry over my .config from version to version. I enabled it and rebuilt the kernel, but in order to get the driver working with this patch i had to also add cma=32M option to kernel arguments. With default of 16M the allocation still fails. Should we add Kconfig dependencies? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 4/5] net: thunderx: Switchon carrier only upon interface link up
Just a reminder, we have issue with this one too, which is not addressed yet.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Sunil
> Goutham
> Sent: Wednesday, December 02, 2015 1:06 PM
> To: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sunil.gout...@caviumnetworks.com; Sunil Goutham
> Subject: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon interface
> link up
>
> From: Sunil Goutham
>
> Call netif_carrier_on() only if interface's link is up. Switching this on
> upon IFF_UP by default, is causing issues with ethernet channel bonding
> in LACP mode. Initial NETDEV_CHANGE notification was being skipped.
>
> Also fixed some issues with link/speed/duplex reporting via ethtool.
>
> Signed-off-by: Sunil Goutham
> ---
> .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 16 +++-
> drivers/net/ethernet/cavium/thunder/nicvf_main.c |4 +---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c |2 ++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> index af54c10..a12b2e3 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
> @@ -112,6 +112,13 @@ static int nicvf_get_settings(struct net_device *netdev,
>
> cmd->supported = 0;
> cmd->transceiver = XCVR_EXTERNAL;
> +
> + if (!nic->link_up) {
> + cmd->duplex = DUPLEX_UNKNOWN;
> + ethtool_cmd_speed_set(cmd, SPEED_UNKNOWN);
> + return 0;
> + }
> +
> if (nic->speed <= 1000) {
> cmd->port = PORT_MII;
> cmd->autoneg = AUTONEG_ENABLE;
> @@ -125,6 +132,13 @@ static int nicvf_get_settings(struct net_device *netdev,
> return 0;
> }
>
> +static u32 nicvf_get_link(struct net_device *netdev)
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> +
> + return nic->link_up;
> +}
> +
> static void nicvf_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *info)
> {
> @@ -660,7 +674,7 @@ static int nicvf_set_channels(struct net_device *dev,
>
> static const struct ethtool_ops nicvf_ethtool_ops = {
> .get_settings = nicvf_get_settings,
> - .get_link = ethtool_op_get_link,
> + .get_link = nicvf_get_link,
> .get_drvinfo= nicvf_get_drvinfo,
> .get_msglevel = nicvf_get_msglevel,
> .set_msglevel = nicvf_set_msglevel,
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 7f709cb..dde8dc7 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1057,6 +1057,7 @@ int nicvf_stop(struct net_device *netdev)
>
> netif_carrier_off(netdev);
> netif_tx_stop_all_queues(nic->netdev);
> + nic->link_up = false;
>
> /* Teardown secondary qsets first */
> if (!nic->sqs_mode) {
> @@ -1211,9 +1212,6 @@ int nicvf_open(struct net_device *netdev)
> nic->drv_stats.txq_stop = 0;
> nic->drv_stats.txq_wake = 0;
>
> - netif_carrier_on(netdev);
> - netif_tx_start_all_queues(netdev);
> -
> return 0;
> cleanup:
> nicvf_disable_intr(nic, NICVF_INTR_MBOX, 0);
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 6534b73..d77e41a 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -612,6 +612,8 @@ static void bgx_poll_for_link(struct work_struct *work)
> lmac->last_duplex = 1;
> } else {
> lmac->link_up = 0;
> + lmac->last_speed = SPEED_UNKNOWN;
> + lmac->last_duplex = DUPLEX_UNKNOWN;
> }
>
> if (lmac->last_link != lmac->link_up) {
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 4/5] net: thunderx: Switchon carrier only upon interface link up
Hello again! > Subject: RE: [PATCH v2 4/5] net: thunderx: Switchon carrier only upon > interface link up > > Just a reminder, we have issue with this one too, which is not addressed yet. I have examined the problem thoroughly and discovered that it is a problem with experimental BGX driver patches on my 4.2 host kernel build. It fails to send NIC_MBOX_MSG_BGX_LINK_CHANGE, so nothing works. I have retested this series on top of 4.3 running on ThunderX. It has good BGX driver and everything works fine. Therefore, the whole series can be safely applied and... Tested-by: Pavel Fedin Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/6] net: thunderx: Increase transmit queue length
Hello! > > So, i see several possible ways to solve this: > > > > 1. Introduce some mechanism which would allow the driver to tell the kernel > > that it needs > > coherent pool of large size. Can be problematic because the driver can be a > > module, and pool > > allocation happens early. > > 2. Can we use some other method for allocating queues, which would not > > require such a huge > > coherent pool? > > 3. The driver could check value of atomic_pool_size and adjust own memory > > requirements > > accordingly. This indeed looks like a quick hack, but would at least make > > things running > > quickly. > > I have also noticed that CONFIG_DMA_CMA is turned off in my kernel. I guess > it was a leftover > from old defconfig, because i carry over my .config from version to version. > I enabled it and > rebuilt the kernel, but in order to get the driver working with this patch i > had to also add > cma=32M option to kernel arguments. With default of 16M the allocation still > fails. > Should we add Kconfig dependencies? After getting it working in guest i tried to apply it to host. With total of 128 virtual functions (= 128 interfaces) it does not work at all. Even after bumping cma region size to insane value of 2GB more than half of interfaces still failed to allocate queues. And after setting cma=3G i could not mount my rootfs. So, absolute NAK, unfortunately. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/6] net: thunderx: Increase transmit queue length
Hello! > >After getting it working in guest i tried to apply it to host. With total of > >128 virtual > functions (= 128 interfaces) it does not work at all. > > Even after bumping cma region size to insane value of 2GB more than half of > > interfaces still > failed to allocate queues. > > And after setting cma=3G i could not mount my rootfs. > > Here what you are saying is half of the interfaces were initialized > succesfully and rest didn't. After setting cma=2G. With default setting of 16M none of them initialized. > So this issue is not something which is introduced by this patch. Before this patch all my interfaces were working. I would say the problem with your patch is that it introduces memory requirements which cannot be satisfied by the platform. It's combination of several factors which stops the thing from working, not a single factor. Using dma_alloc_coherent() is not all wrong by itself, of course. Perhaps you did some tricks with your configuration, which make it working. Then, i guess, you should have at least described them in commit message of your patch. Or describe all dependencies in KConfig of your driver, which is better. Or, if the platform needs some very special defconfig, add it to arch/arm64/configs (however, i guess, the goal of ARM64 Linux is to run on all possible hardware, so this would not be good from maintainers' POV). Sorry, but this is all i can say. In previous messages i have already suggested several ways to solve the problem (too lazy to quite here, 4 IIRC), or you can suggest your own one and let us test it, or you can even stick to "It works for me, i am the only right guy in the world, and i don't care if it doesn't work for you" position and let David decide who of us is right (and he already did that once). Basically, here is what i did: i took kernel 4.2, added ThunderX PCI drivers to it (they were posted but NAKed those days back, there's some lazy progress on them currently), added necessary errata patches (also posted on lists, all merged into 4.4), took defconfig, adjusted it according to my needs, and this is what i'm running on my board and this is what i'm using for development. If you point me at what i'm doing wrong way, i'll be glad to accept this. I'm over. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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.3 23/71] net: thunder: Check for driver data in nicvf_remove()
Hello!
It's good to apply this to stable, however IMHO commit message should be
changed. Actually, this was fix for a fix, so in theory
5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206 and
7750130d93decff06120df0d8ea024ff8a038a21 should have been squashed together.
You can
take a commit message from 5883d9c6d7e680bcdc7a8a9ed2509cd10dd98206, it better
explains what was actually done and why.
There's also a clean patch:
https://www.mail-archive.com/netdev@vger.kernel.org/msg87010.html, which was
not applied because v1 was
already applied and David doesn't revert commits.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, December 12, 2015 11:06 PM
> To: linux-kernel@vger.kernel.org
> Cc: Greg Kroah-Hartman; sta...@vger.kernel.org; Pavel Fedin; David S. Miller
> Subject: [PATCH 4.3 23/71] net: thunder: Check for driver data in
> nicvf_remove()
>
> 4.3-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Pavel Fedin
>
> [ Upstream commit 7750130d93decff06120df0d8ea024ff8a038a21 ]
>
> In some cases the crash is caused by nicvf_remove() being called from
> outside. For example, if we try to feed the device to vfio after the
> probe has failed for some reason. So, move the check to better place.
>
> Signed-off-by: Pavel Fedin
> Signed-off-by: David S. Miller
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1583,8 +1583,14 @@ err_disable_device:
> static void nicvf_remove(struct pci_dev *pdev)
> {
> struct net_device *netdev = pci_get_drvdata(pdev);
> - struct nicvf *nic = netdev_priv(netdev);
> - struct net_device *pnetdev = nic->pnicvf->netdev;
> + struct nicvf *nic;
> + struct net_device *pnetdev;
> +
> + if (!netdev)
> + return;
> +
> + nic = netdev_priv(netdev);
> + pnetdev = nic->pnicvf->netdev;
>
> /* Check if this Qset is assigned to different VF.
>* If yes, clean primary and all secondary Qsets.
>
--
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: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver
Hello! > THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES > > Series v5 got merged in kgene/for-next but due to last moment change before > pull > these patches were not accepted during 4.3 merge window.After that > kgene/for-next > got rebased over 4.4-rc1 these patches got dropped into another branch and > till > date not included to for-next. I will not strictly require it because i'd like to move on with this somehow, and if this gets merged, i'm fine with it, but if you happen to send v6, may be you should include this small bit: http://www.spinics.net/lists/linux-samsung-soc/msg49008.html ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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.3 23/71] net: thunder: Check for driver data in nicvf_remove()
Hello! > stable patches should always match what is in Linus's tree, so I'm not > going to change the commit messages, sorry. Ok, no problem, i just wanted to suggest it to make more sense, because this msg alone doesn't explain anything. But, well, i understand that administrative rules always have priority. So let it just be this way. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 1/2] net: thunderx: HW TSO support for pass-2 hardware
ntry, subdesc_cnt - 1,
> + skb, skb->len);
>
> /* Add SQ gather subdescs */
> qentry = nicvf_get_nxt_sqentry(sq, qentry);
> diff --git a/drivers/net/ethernet/cavium/thunder/q_struct.h
> b/drivers/net/ethernet/cavium/thunder/q_struct.h
> index 3c1de97..9e6d987 100644
> --- a/drivers/net/ethernet/cavium/thunder/q_struct.h
> +++ b/drivers/net/ethernet/cavium/thunder/q_struct.h
> @@ -545,25 +545,28 @@ struct sq_hdr_subdesc {
> u64subdesc_cnt:8;
> u64csum_l4:2;
> u64csum_l3:1;
> - u64rsvd0:5;
> + u64csum_inner_l4:2;
> + u64csum_inner_l3:1;
> + u64rsvd0:2;
> u64l4_offset:8;
> u64l3_offset:8;
> u64rsvd1:4;
> u64tot_len:20; /* W0 */
>
> - u64tso_sdc_cont:8;
> - u64tso_sdc_first:8;
> - u64tso_l4_offset:8;
> - u64tso_flags_last:12;
> - u64tso_flags_first:12;
> - u64rsvd2:2;
> + u64rsvd2:24;
> + u64inner_l4_offset:8;
> + u64inner_l3_offset:8;
> + u64tso_start:8;
> + u64rsvd3:2;
> u64tso_max_paysize:14; /* W1 */
> #elif defined(__LITTLE_ENDIAN_BITFIELD)
> u64tot_len:20;
> u64rsvd1:4;
> u64l3_offset:8;
> u64l4_offset:8;
> - u64rsvd0:5;
> + u64rsvd0:2;
> + u64csum_inner_l3:1;
> + u64csum_inner_l4:2;
> u64csum_l3:1;
> u64csum_l4:2;
> u64subdesc_cnt:8;
> @@ -574,12 +577,11 @@ struct sq_hdr_subdesc {
> u64subdesc_type:4; /* W0 */
>
> u64tso_max_paysize:14;
> - u64rsvd2:2;
> - u64tso_flags_first:12;
> - u64tso_flags_last:12;
> - u64tso_l4_offset:8;
> - u64tso_sdc_first:8;
> - u64tso_sdc_cont:8; /* W1 */
> + u64rsvd3:2;
> + u64tso_start:8;
> + u64inner_l3_offset:8;
> + u64inner_l4_offset:8;
> + u64rsvd2:24; /* W1 */
> #endif
> };
>
> --
> 1.7.1
>
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 2/2] net: thunderx: Enable CQE count threshold interrupt
Hello! > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Sunil > Goutham > Sent: Wednesday, December 09, 2015 2:38 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > p.fe...@samsung.com; > sunil.gout...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 2/2] net: thunderx: Enable CQE count threshold interrupt > > From: Sunil Goutham > > This feature is introduced in pass-2 chip and with this CQ interrupt > coalescing will work based on both timer and count. > > Signed-off-by: Sunil Goutham > --- > drivers/net/ethernet/cavium/thunder/nic.h |2 ++ > drivers/net/ethernet/cavium/thunder/nicvf_main.c |2 +- > drivers/net/ethernet/cavium/thunder/nicvf_queues.c |5 - > drivers/net/ethernet/cavium/thunder/nicvf_queues.h |3 ++- > 4 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h > b/drivers/net/ethernet/cavium/thunder/nic.h > index 02571f4..e782856 100644 > --- a/drivers/net/ethernet/cavium/thunder/nic.h > +++ b/drivers/net/ethernet/cavium/thunder/nic.h > @@ -34,6 +34,8 @@ > /* NIC priv flags */ > #define NIC_SRIOV_ENABLED BIT(0) > > +#define VNIC_NAPI_WEIGHTNAPI_POLL_WEIGHT > + > /* Min/Max packet size */ > #define NIC_HW_MIN_FRS 64 > #define NIC_HW_MAX_FRS 9200 /* 9216 max packet > including FCS */ > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > index c24cb2a..e06a7f8 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c > @@ -1155,7 +1155,7 @@ int nicvf_open(struct net_device *netdev) > cq_poll->cq_idx = qidx; > cq_poll->nicvf = nic; > netif_napi_add(netdev, &cq_poll->napi, nicvf_poll, > -NAPI_POLL_WEIGHT); > +VNIC_NAPI_WEIGHT); What's the sense in introducing another constant which is aliased to the previous one? Making LOC bigger? > napi_enable(&cq_poll->napi); > nic->napi[qidx] = cq_poll; > } > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > index b11fc09..4e9709e 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c > @@ -299,7 +299,10 @@ static int nicvf_init_cmp_queue(struct nicvf *nic, > return err; > > cq->desc = cq->dmem.base; > - cq->thresh = CMP_QUEUE_CQE_THRESH; > + if (!pass1_silicon(nic->pdev)) > + cq->thresh = CMP_QUEUE_CQE_THRESH; > + else > + cq->thresh = 0; IMHO "cq->thresh = pass1_silicon(nic->pdev) ? CMP_QUEUE_CQE_THRESH : 0" looks less bulky. > nic->cq_coalesce_usecs = (CMP_QUEUE_TIMER_THRESH * 0.05) - 1; > > return 0; > diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > index a4f6667..0fae6ad 100644 > --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h > @@ -10,6 +10,7 @@ > #define NICVF_QUEUES_H > > #include > +#include "nic.h" > #include "q_struct.h" > > #define MAX_QUEUE_SET128 > @@ -75,7 +76,7 @@ > */ > #define CMP_QSIZECMP_QUEUE_SIZE2 > #define CMP_QUEUE_LEN(1ULL << (CMP_QSIZE + 10)) > -#define CMP_QUEUE_CQE_THRESH 0 > +#define CMP_QUEUE_CQE_THRESH (VNIC_NAPI_WEIGHT / 2) > #define CMP_QUEUE_TIMER_THRESH 80 /* ~2usec */ > > #define RBDR_SIZERBDR_SIZE0 > -- > 1.7.1 Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..da6a8fa0e 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,15 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
@@ -133,6 +142,12 @@
<10 &gic 0 130 0>,
<11 &gic 0 131 0>;
};
+
+ arch_timer {
+ compatible = "arm,armv7-timer";
+ clock-frequency = <2400>;
+ };
+
};
sysram@0202 {
--
2.4.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/
[PATCH v4 0/4] [PATCH v4 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board, which is connected via SROMc bank #3. With this patchset, support for the whole existing SMDK range can be added. Actually, only bank number is different. This patchset also depends on Exynos 5410 pinctrl support, introduced by patches 0003 and 0004 from this set: [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html Pinctrl support is necessary in order to correctly configure multifunctional pins of the Exynos chip. v3 => v4: - Devices are now added as subnodes, with additional properties. This allows to cleary specify dependency. If configuration fails, error will be reported and child devices will not be probed. - These additional properties now have "samsung,srom-XXX" format - Fixed code style, now better understood. v2 => v3: - Fixed up SROMc region size in the device tree - Reordered patches, documentation goes first now v1 => v2: - Fixed some typos and bad labels in device tree - Improved documentation Pavel Fedin (4): Documentation: dt-bindings: Describe SROMc configuration ARM: dts: Add SROMc to Exynos 5410 drivers: exynos-srom: Add support for bank configuration ARM: dts: Add Ethernet chip to SMDK5410 .../bindings/arm/samsung/exynos-srom.txt | 50 ++- arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++ arch/arm/boot/dts/exynos5410.dtsi | 15 ++ arch/arm/mach-exynos/Kconfig | 2 +- drivers/soc/samsung/Kconfig| 2 +- drivers/soc/samsung/exynos-srom.c | 58 +- 6 files changed, 162 insertions(+), 6 deletions(-) -- 2.4.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/
[PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Signed-off-by: Pavel Fedin
---
.../bindings/arm/samsung/exynos-srom.txt | 50 +-
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..02ecc7f 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,54 @@ Required properties:
- reg: offset and length of the register set
-Example:
+- #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property.
+- ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The SROM controller can be used to attach external peripherials. In this case
+device nodes should be added as subnodes to the SROMc node. These subnodes,
+except regular device specification, should contain the following properties,
+describing configuration of the relevant SROM bank:
+
+Required properties:
+- samsung,srom-bank : bank number (0 - 3)
+
+- samsung,srom-timing : array of 7 integers: PMC, Tacp, Tcah, Tcoh, Tacc, Tcos,
+ Tacs
+
+Optional properties:
+- samsung,srom-data-width : data width in bytes (1 or 2). If omitted, default
+ of 1 is used.
+
+Example: basic definition, no banks are configured
sromc@1257 {
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with smsc 911x ethernet chip on bank 3
+ sromc@1257 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+
+ ethernet@0700 {
+ compatible = "smsc,lan9115";
+ reg = <0x0700 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-bank = <3>;
+ samsung,srom-data-width = <2>;
+ samsung,srom-timing = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.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/
[PATCH v4 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..311e7be 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -61,6 +61,27 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
&uart0 {
status = "okay";
};
@@ -72,3 +93,23 @@
&uart2 {
status = "okay";
};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@0700 {
+ compatible = "smsc,lan9115";
+ reg = <0x0700 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-bank = <3>;
+ samsung,srom-data-width = <2>;
+ samsung,srom-timing = <1 9 12 1 9 1 1>;
+ };
+};
--
2.4.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/
[PATCH v4 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 58 +--
3 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..68e894f 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,48 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
+{
+ u32 bank, width;
+ u32 timing[7];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "samsung,srom-bank", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "samsung,srom-data-width", &width))
+ width = 1;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((timing[0] << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[6] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+ bool error = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +138,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (decode_sromc(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ error = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (error)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.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: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
Hello! > I applied (with fixes mentioned in my comments) everything and pushed > here so everyone could play with it: > https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc- > exynos-srom-2 I see the last patch (adding Ethernet chip to DT) is missing. Is it intentional, so that it goes later? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia
RE: [PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > > This patchset also depends on Exynos 5410 pinctrl support, introduced by > > patches 0003 and 0004 from this set: > > [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > > Only the first patch made up to kernel. The rest (2-5) received feedback > and I am waiting for fixing it. Andreas apparently loose the interest... I have rechecked the original thread on archives and found nothing new. Where can i read those feedbacks? Perhaps it makes sense for me to pick them up and include into my set. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > >>> This patchset also depends on Exynos 5410 pinctrl support, introduced by > >>> patches 0003 and 0004 from this set: > >>> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > >> > >> Only the first patch made up to kernel. The rest (2-5) received feedback > >> and I am waiting for fixing it. Andreas apparently loose the interest... > > > > I have rechecked the original thread on archives and found nothing new. > > Where can > > i read those feedbacks? Perhaps it makes sense for me to pick them up and > > include > > into my set. > > Go ahead. The only waiting feedback is at patch 2/5: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330910.html > Javier's pointed use of linux,stdout-path and putting xxti in > exynos5410.dtsi (and customizing it per board if needed). > > Patches already got reviews and acks so only 2/5 is the stopper. Ah, it's odroidXU device tree. Sorry, i don't have this particular board, and my patch actually doesn't need it. I could do some blind modifications, but cannot test them, and this is out of my scope at all. As mentioned in the commit msg, i need only 0003 and 0004 from there. Can they be picked up independently? They don't need 0002 by themselves, only 0005 needs it. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > >>>>> This patchset also depends on Exynos 5410 pinctrl support, introduced by > >>>>> patches 0003 and 0004 from this set: > >>>>> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs > >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html > >>>> > >>>> Only the first patch made up to kernel. The rest (2-5) received feedback > >>>> and I am waiting for fixing it. Andreas apparently loose the interest... > >>> > >>> I have rechecked the original thread on archives and found nothing new. > >>> Where can > >>> i read those feedbacks? Perhaps it makes sense for me to pick them up and > >>> include > >>> into my set. > >> > >> Go ahead. The only waiting feedback is at patch 2/5: > >> > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330910.html > >> Javier's pointed use of linux,stdout-path and putting xxti in > >> exynos5410.dtsi (and customizing it per board if needed). > >> > >> Patches already got reviews and acks so only 2/5 is the stopper. > > > > Ah, it's odroidXU device tree. Sorry, i don't have this particular board, > > and my patch > actually doesn't need it. I could do some > > blind modifications, but cannot test them, and this is out of my scope at > > all. > > As mentioned in the commit msg, i need only 0003 and 0004 from there. Can > > they be picked up > independently? They don't need 0002 by > > themselves, only 0005 needs it. > > Indeed the order of patches is messed up and this makes the confusion. I > was waiting for resend of entire patchset but you are right - this is > not required. 3 and 4 can be applied independently. > > If they apply, I will pick up them after merge window. They should. I have quite recent linux-next tree, i've just checked, 0003 applies with a small fuzz and 0004 applies without problems at all. > If they don't, they will need rebasing by someone. Maybe you can take > care of them? Of course. Please notify me if rebasing will be needed, i'll do it. > You have the SMDK5410 for testing, right? Of course. And you can already get my Tested-by: Pavel Fedin on those two because my experimental tree already uses them, and everything works quite well. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 3/4] drivers: exynos-srom: Add support for bank configuration
Hello!
> > +static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
>
> I missed that one previously: add prefix and more descriptive name, like:
> exynos_srom_parse_child()
exynos_srom_configure_bank(), is this name OK?
> > static int exynos_srom_probe(struct platform_device *pdev)
> > {
> > - struct device_node *np;
> > + struct device_node *np, *child;
> > struct exynos_srom *srom;
> > struct device *dev = &pdev->dev;
> > + bool error = false;
>
> The 'error' name is misleading - like error for entire probe which is
> not true.
>
> Instead split it to separate function like:
>
> +static int exynos_srom_parse_children() {
> + int ret = 0;
> +
> + for_each_child_of_node(np, child) {
> + ret = exynos_srom_parse_child(srom, child);
> + if (ret) {
> + dev_err(dev,
> + "Could not decode bank configuration for %s:
> %d\n",
> + child->name, ret);
> + break;
> + }
> + }
> +
> + return ret;
> +}
Factoring out this loop is unnecessary, because i could just 'return 0' in the
loop
instead of 'error = true'. Byt my idea is to go through all banks anyway, just
in
case, to diagnose all of them. So that the user will be able to spot and fix all
broken banks at once, instead of doing one-by-one.
I have renamed the variable to 'bool bad_bank_config', will this be OK?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 4/4] ARM: dts: Add Ethernet chip to SMDK5410
Hello!
> > + ethernet@3 {
> > + compatible = "smsc,lan9115";
> > + reg = <3 0 0x1>;
> > + phy-mode = "mii";
> > + interrupt-parent = <&gpx0>;
> > + interrupts = <5 8>;
>
> s/8/IRQ_TYPE_LEVEL_LOW/
> (is this really level low interrupt?)
Yes, according to:
https://github.com/AndreiLux/Perseus-S3/blob/master/arch/arm/mach-exynos/mach-smdk5250.c#L133
> Some other DTS include regulators: vddvario-supply and vdd33a-supply. It
> seems that they are not described in SMSC911x bindings but in
> GPMC-eth... but the smsc911x driver is requesting them. Could you
> investigate that? I think these regulators should be provided (and
> SMSC911x bindings should be updated).
Sorry, i cannot. The board has lots of jumpers, which choose between fixed
voltage and regulators for different components,
according to board's manual, but the manual is very poor IMHO, and i don't
understand how to use them. And i use default,
fixed-voltage configuration.
One of my colleagues tried to get it working, but failed. It actually requires
more time, and IIRC you need to bring up i2c before
you can drive regulators.
So can we leave it as it is for now? At least it works, and this is much
better than no ethernet support at all.
> I don't have the board schematics so I couldn't verify the GPIOs.
Me neither, i wrote GPIO settings according to chip datasheet i have. They are
actually chip-specific, but i wrote them in board
file because on different boards you may use different banks, and therefore
different pins. Or, if you don't use SROMc at all, you
can configure all pins to do something else.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 4/4] ARM: dts: Add Ethernet chip to SMDK5410
Hello!
> >>> + ethernet@3 {
> >>> + compatible = "smsc,lan9115";
> >>> + reg = <3 0 0x1>;
> >>> + phy-mode = "mii";
> >>> + interrupt-parent = <&gpx0>;
> >>> + interrupts = <5 8>;
> >>
> >> s/8/IRQ_TYPE_LEVEL_LOW/
> >> (is this really level low interrupt?)
> >
> > Yes, according to:
> > https://github.com/AndreiLux/Perseus-S3/blob/master/arch/arm/mach-
> exynos/mach-smdk5250.c#L133
>
> Although this is different board, but okay.
I am curious too, so i examined SMSC datasheet. The IRQ is fully programmable
on
chip's side too, and our driver indeed defaults to active-low. You can switch it
to active-high by addint smsc,irq-active-high property. But i just copied
settings from those old Android kernels, and it just works.
So, cleaning up and posting v6.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 v6 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
---
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..cce5c1f 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,75 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 32)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-config = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.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/
[PATCH v6 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", &width))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.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/
[PATCH v6 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.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/
[PATCH v6 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 ++-
6 files changed, 182 insertions(+), 6 deletions(-)
--
2.4.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/
[PATCH v6 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.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] Documentation: dt-bindings: Describe SROMc configuration
Hello! > > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the > > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, > > Tacs. > > +Each value is specified in cycles and has the > > following > > +meaning and valid range: > > +Tacp : Page mode access cycle at Page mode (0 - 15) > > +Tcah : Address holding time after CSn (0 - 15) > > +Tcoh : Chip selection hold on OEn (0 - 15) > > +Tacc : Access cycle (0 - 32) > > All of the manuals have error here. Probably it can be either: 1-32 or > 0-31. I would bet on 0-31, what do you think? Damn, everything starts from 0, so i automatically put '0 - 32'. The actual time, however, varies from 1 to 32, but the value is from 0 to 31, i. e. - 1 What shall we do? Just document this, or adjust the code to take number of cycles and subtract 1? To tell the truth, i'm already sick of these small fixups, and i would prefer just to fix documentation. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", &width))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.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/
[PATCH v7 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 ++-
6 files changed, 182 insertions(+), 6 deletions(-)
--
2.4.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/
[PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/arm/samsung/exynos-srom.txt | 71 +-
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..3ff2950 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,75 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-config = <1 9 12 1 9 1 1>;
+ };
};
--
2.4.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/
[PATCH v7 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.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/
[PATCH v7 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..373abf7 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.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 v4 2/4] ARM: dts: Add SROMc to Exynos 5410
Hello!
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org
> [mailto:linux-samsung-soc-ow...@vger.kernel.org]
> On Behalf Of Pankaj Dubey
> Sent: Thursday, October 29, 2015 8:28 PM
> To: Pavel Fedin
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-soc;
> linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala;
> Kukjin Kim; Krzysztof Kozlowski
> Subject: Re: [PATCH v4 2/4] ARM: dts: Add SROMc to Exynos 5410
>
> Hi Pavel,
>
> On 29 October 2015 at 18:12, Pavel Fedin wrote:
> > This machine uses own SoC device tree file, add missing part.
> >
> > Signed-off-by: Pavel Fedin
> > ---
> > arch/arm/boot/dts/exynos5410.dtsi | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5410.dtsi
> > b/arch/arm/boot/dts/exynos5410.dtsi
> > index 4603356..da6a8fa0e 100644
> > --- a/arch/arm/boot/dts/exynos5410.dtsi
> > +++ b/arch/arm/boot/dts/exynos5410.dtsi
> > @@ -101,6 +101,15 @@
> > reg = <0x1000 0x100>;
> > };
> >
> > + sromc: sromc@1225 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
>
> We do not need to specify these three properties as they are already
> present in parent node "soc".
We do, otherwise dtc complains about defaults of #address-cells = 2 and
#size-cells=1, and without empty "ranges" subnode's resources are not correctly
translated.
>
> > + compatible = "samsung,exynos-srom";
> > + reg = <0x1225 0x14>;
> > + };
> > +
> > pmu_system_controller: system-controller@1004 {
> > compatible = "samsung,exynos5410-pmu", "syscon";
> > reg = <0x1004 0x5000>;
> > @@ -133,6 +142,12 @@
> > <10 &gic 0 130 0>,
> > <11 &gic 0 131 0>;
> > };
> > +
> > + arch_timer {
> > + compatible = "arm,armv7-timer";
> > + clock-frequency = <24000000>;
> > + };
> > +
>
> This change should not be part of this patch.
Ooops, thank you very much, this should not have been here at all. This is a
leftover from my experiments, i was tracing DT parsing code and added it just
for test, to see why timer gets probed as a subnode.
Just forgot to remove it afterwards and it slipped into the patch.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 0/4] [PATCH v4 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > > .../bindings/arm/samsung/exynos-srom.txt | 50 ++- > > arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++ > > arch/arm/boot/dts/exynos5410.dtsi | 15 ++ > > arch/arm/mach-exynos/Kconfig | 2 +- > > drivers/soc/samsung/Kconfig| 2 +- > > drivers/soc/samsung/exynos-srom.c | 58 > > +- > > 6 files changed, 162 insertions(+), 6 deletions(-) > > > > Something wrong here, I am not able to find V4 1/4 and 3/4 in this mailing > list. Which mailing list is "this"? I've just rechecked, i've got my messages back on both (linux-samsung-soc and linux-arm-kernel). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > Add documentation for new subnode properties, allowing bank configuration.
> > Based on u-boot implementation, but heavily reworked.
>
> Please, carefully look at:
> Documentation/devicetree/bindings/net/gpmc-eth.txt
> Documentation/devicetree/bindings/bus/ti-gpmc.txt
Thank you very much. Indeed, this looks very similar. By the way, should i
document smsc over sromc in the same manner, writing
devicetree/bindings/net/sromc-eth.txt?
This is a short reply for now, i'll make longer one (or just a new version)
after studying these existing bindings and trying to
apply them.
Pankaj:
> > +&sromc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
> > +
> > + ethernet@0700 {
> > + compatible = "smsc,lan9115";
> > + reg = <0x0700 0x1>;
> > + phy-mode = "mii";
> > + interrupt-parent = <&gpx0>;
> > + interrupts = <5 8>;
> > + reg-io-width = <2>;
> > + smsc,irq-push-pull;
> > + smsc,force-internal-phy;
> > +
> > + samsung,srom-bank = <3>;
> > + samsung,srom-data-width = <2>;
> > + samsung,srom-timing = <1 9 12 1 9 1 1>;
>
> I think this is not correct. We can't change binding of "smsc,lan9115"
> which is already documented here [1]. These samsung specific srom
> properties should be in srom node or its subnode, but not in this way.
So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly
valid (this is a reply to another msg, just don't want
to post one more single-line reply).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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] net: smsc911x: Reset PHY during initialization
On certain hardware after software reboot the chip may get stuck and fail
to reinitialize during reset. This can be fixed by ensuring that PHY is
reset too.
Old PHY resetting method required operational MDIO interface, therefore
the chip should have been already set up. In order to be able to function
during probe, it is changed to use PMT_CTRL register.
The problem could be observed on SMDK5410 board.
Signed-off-by: Pavel Fedin
---
drivers/net/ethernet/smsc/smsc911x.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index c860c90..219a99b 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -809,22 +809,17 @@ static int smsc911x_phy_check_loopbackpkt(struct
smsc911x_data *pdata)
static int smsc911x_phy_reset(struct smsc911x_data *pdata)
{
- struct phy_device *phy_dev = pdata->phy_dev;
unsigned int temp;
unsigned int i = 10;
- BUG_ON(!phy_dev);
- BUG_ON(!phy_dev->bus);
-
- SMSC_TRACE(pdata, hw, "Performing PHY BCR Reset");
- smsc911x_mii_write(phy_dev->bus, phy_dev->addr, MII_BMCR, BMCR_RESET);
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ smsc911x_reg_write(pdata, PMT_CTRL, temp | PMT_CTRL_PHY_RST_);
do {
msleep(1);
- temp = smsc911x_mii_read(phy_dev->bus, phy_dev->addr,
- MII_BMCR);
- } while ((i--) && (temp & BMCR_RESET));
+ temp = smsc911x_reg_read(pdata, PMT_CTRL);
+ } while ((i--) && (temp & PMT_CTRL_PHY_RST_));
- if (temp & BMCR_RESET) {
+ if (unlikely(temp & PMT_CTRL_PHY_RST_)) {
SMSC_WARN(pdata, hw, "PHY reset failed to complete");
return -EIO;
}
@@ -2296,7 +2291,7 @@ static int smsc911x_init(struct net_device *dev)
}
/* Reset the LAN911x */
- if (smsc911x_soft_reset(pdata))
+ if (smsc911x_phy_reset(pdata) || smsc911x_soft_reset(pdata))
return -ENODEV;
dev->flags |= IFF_MULTICAST;
--
2.4.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 v4 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> Please, carefully look at:
> Documentation/devicetree/bindings/net/gpmc-eth.txt
> Documentation/devicetree/bindings/bus/ti-gpmc.txt
>
> 1. Try to re-use existing bindings. Although I see existing bank-width
> and gpmc,device-width but yours samsung,srom-data-width seems better.
> Maybe there are other to re-use?
I've done this and this is what i currently came up with. I'd like to discuss
this before respin because nobody needs this
back-and-forth bouncing.
--- cut exynos5410.dtsi ---
sromc: sromc@1225 {
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x0400 0x2
1 0 0x0500 0x2
2 0 0x0600 0x2
3 0 0x0700 0x2>;
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
};
--- cut exynos5410.dtsi ---
--- cut exynos5410-smdk5410.dts ---
&sromc {
pinctrl-names = "default";
pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
ethernet@3 {
compatible = "smsc,lan9115";
reg = <3 0 0x1>;
phy-mode = "mii";
interrupt-parent = <&gpx0>;
interrupts = <5 8>;
reg-io-width = <2>;
smsc,irq-push-pull;
smsc,force-internal-phy;
samsung,srom-config = <1 9 12 1 9 1 1>;
};
};
--- cut exynos5410-smdk5410.dts ---
1. After writing proper ranges i was able to get rid of dedicated bank number
property, because now it is the first value in
device's "reg".
2. I noticed that smsc binding already uses reg-io-width property. I searched
for it, and it appears to be reused by many devices.
So, i decided to use it to specify bank width, since it's already there.
ti-gpmc uses bank-width because it supports configurations
like reg-io-width = 4 && bank-width = 2. I don't know if it's possible to do
the same with SROMc, Exynos doc doesn't tell anything
about 32-bit accesses. But, if you want to support it too, i would suggest the
following algorithm:
if (have bank-width)
width = bank-width
else if (have reg-io-width)
width = reg-io-width
else
width = 1 /* default */
3. About samsung,srom-config array. I have the following reasons to keep if
this way:
- listing every property under own name is just too much typing
- these values really do not make sense without each other, or partialy. I
would say that in array form they are even better
readable, because it is the same order in which they go into the register.
However, it is still a nice idea do document them, but...
my PDF has "confidential" watermark on it, and this would mean that i
essentially copy some information from it into Linux doc. Is
it okay to do this?
If you still dislike the array, i'll redo is a set of properties like
samsung,srom-tacs, samsung,srom-tcos, etc.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 2/4] ARM: dts: Add SROMc to Exynos 5410
Hello!
> >>> + sromc: sromc@1225 {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <1>;
> >>> + ranges;
> >>> +
> >>
> >> We do not need to specify these three properties as they are already
> >> present in parent node "soc".
> >
> > We do, otherwise dtc complains about defaults of #address-cells = 2 and
> > #size-cells=1, and
> without empty "ranges" subnode's resources are not correctly translated.
> >
>
> First of all this patch will not give this error. So this part should
> not be a part of this patch.
> You should be getting above error after applying v4 4/4 "ARM: dts: Add
> Ethernet chip to SMDK5410". So if its failing for ethernet subnode, you
> can move this address-cells and size-cells in dts file just above
> ethernet node as shown below:
>
> index 311e7be..d69981d 100644
> --- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
> +++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
> @@ -95,6 +95,9 @@
> };
>
> &sromc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> pinctrl-names = "default";
> pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
>
IMHO this makes little of sense, because in this case you would have to
duplicate these properties for every supported machine. address-cells,
size-cells and ranges belong to the controller itself, not to its children.
Of course i could split up the patch into two, first introduce sromc, second
introduce mapping. But does it worth that? Both patches would be 3 lines of
code each.
Anyway, this specific talk is outdated by now, please check out neighbor
topic, we are discussing significantly improved binding with Krzystof.
> And another question still remains open, we can't just like that change
> "smsc,lan9115" binding by adding samsung specific properties.
I am sorry, but you either do not understand us with Krzystof, or not reading
at all...
This is not a change in the binding. And these properties do not belong to
smsc at all. They would be added to *ANY* device which sits on top of SROMc.
This is more like a bus-specific extra. It's similar to "reg" property having
different meanings for different buses.
> Probably you can check suggestions from Krzysztof, where he pointed out
> some hint on how other places this is getting used.
Did you read them? I did, and they do exactly the same thing as i do.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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: smsc911x: Reset PHY during initialization
Hello!
> > On certain hardware after software reboot the chip may get stuck and fail
> > to reinitialize during reset. This can be fixed by ensuring that PHY is
> > reset too.
> >
> > Old PHY resetting method required operational MDIO interface, therefore
> > the chip should have been already set up. In order to be able to function
> > during probe, it is changed to use PMT_CTRL register.
> >
> > The problem could be observed on SMDK5410 board.
> >
> > Signed-off-by: Pavel Fedin
>
> I'm pretty sure this is going to break the PHY loopback test.
It's not (at least in normal situation), because first we do the test, and
only then, if it fails, we reset the PHY. So, during
normal operation of the driver, when loopback test succeeds at first attempt,
we never attempt to reset the PHY. And, by the way, at
least on my board this PHY reset did nothing useful, because after it loopback
test still failed, all 100 times.
And, we don't use PHY reset anywhere outside of loopback test.
> This is such a tricky and fragile area to get right, therefore I
> want you to specifically guard any change in how PHY reset is
> done with tests against the specific chips that have the problem.
Well, i could do one (or some combination) of the following, if you really
want to:
a) Leave PHY reset inside loopback test as it is, but add a second routine and
call it only before smsc911x_soft_reset().
b) Reset PHY only conditionally, using the following algorithm:
if smsc911x_soft_reset() {
/* NIC reset failed, kick the PHY and retry */
smsc911x_phy_reset()
if (smsc_911x_soft_reset())
return -ENODEV;
}
c) Do extra PHY reset only if some hint in device tree is specified (or the
machine is known to have the problem)
But, i dislike approach (a) for code duplication, because datasheet says that
both reset methods are equivalent; i dislike approach
(b) for actually being a hack; and i dislike (c) for adding extra stuff which
seems to be not necessary. After all, what is wrong
with just extra PHY reset before attempting to program anything? By the way, i
test my patch with both software reboot and hardware
reboot, and even powercycle. Everything is quite stable.
Well, it's up to you to decide. But i'd like to get the fix upstreamed somehow
because from time to time we use these boards for
tests, and it's quite annoiying to be unable to reboot them properly.
> Furthermore, I want you to test whether this has any negative
> effects on the PHY loopback test.
I did. I never disabled loopback test, so i actually discovered a problem
(even two) with it. First, the problem was chip reset
timeout. By increasing it to 300ms this problem seemed to be fixed, but
loopback test started to fail. This was how i found and
fixed crash with missing phy_disconnect(). I examined the code and discovered
that upon loopback test failure we reset the PHY and
retry. But in my case this PHY reset never did the right thing, and all
loopback attempts (10x10 IIRC) were failing.
Some comments in the code gave me a clue that the main NIC can misbehave on
reset if e.g. PHY is in powerdown state. I printed
value of its control register and discovered that it was not the case. But then
i discovered that we actually never try to reset the
PHY before doing anything. Also, while studying the datasheed i discovered that
there is a shorthand for resetting PHY without MDIO
bus set up, but our driver doesn't use it, preferring MDIO method instead,
which already requires operational NIC.
So, i suggested that PHY is just not being reset when board is rebooted by
software. I wrote the patch and it worked. I verified it
by reverting my previous NIC reset timeout increase, and it continued to work.
After this loopback test on my board passes at first
attempt.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > --- cut exynos5410.dtsi ---
> > sromc: sromc@1225 {
> > #address-cells = <2>;
> > #size-cells = <1>;
> > ranges = <0 0 0x0400 0x2
> > 1 0 0x0500 0x2
> > 2 0 0x0600 0x2
> > 3 0 0x0700 0x2>;
>
> Do you have to use 2 cells for address? Cannot it be:
> ranges = <0 0x0400 0x2
> 1 0x0500 0x2
> 2 0x0600 0x2
> 3 0x0700 0x2>;
I tried this first, but it didn't work, and ranges translation
gave me something really weird (like addr = 0x80 and
size = 0x0404). I decided not to dig deeply into
"ranges" processing, but just followed GPMC approach. They say
that first number is range ID and second number is offset within
the range. And it just worked.
> > 3. About samsung,srom-config array. I have the following reasons to keep
> > if this way:
> > - listing every property under own name is just too much typing
> > - these values really do not make sense without each other, or
> > partialy. I would say
> that in array form they are even better
> > readable, because it is the same order in which they go into the register.
>
> For timings - OK. PMC is separate. This is not a timing.
But it's srom-config, and not srom-timing anymore. So do you want
two properties like srom-timing + srom-page-mode (with vendor prefix
of course)?
> You need to document them. We are not gonna put some data looking like a
> vendor blob into the binding. I understand that document has
> confidential mark... all of Samsung datasheets I've seen had it. I don't
> find it as problem but of course I am not the one to judge here. If you
> do not feel comfortable publishing such data, get an approval from your
> manager. You can also try to search for this in vendor code
> (opensource.samsung.com). If it is published there, then this won't be a
> disclosure.
I've seen the actual SROMc settings in some old Android kernels, like 3.0.4.
But they are not documented there, no comments, just #define's.
Ok, i'll try to take a look how to minimize the actual information. :)
> BTW, your email client is weird. You are sending non-wrapped emails
> without format=flowed in Content-Type. Please stick to mailing list
> convention of wrapping at 72-char.
I know, sorry, this is MS Outlook (not Express), and it's impossible
to configure it this way (if i just set up word wrap, it starts to
corrupt patches). I am now trying to wrap the text by hands, i hope
it's better. And i cannot use anything else because... You know why. :)
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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/
[RESEND PATCH] Avoid conflict with host definitions when cross-compiling
Certain platforms (e. g. BSD-based ones) define some ELF constants according to host. This patch fixes problems with cross-building Linux kernel on these platforms. Signed-off-by: Pavel Fedin --- P.S. If you are not fond of mentioning Cygwin in the comment, feel free to change it to "BSD-based" --- scripts/mod/modpost.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h index 168b43d..9f51365 100644 --- a/scripts/mod/modpost.h +++ b/scripts/mod/modpost.h @@ -11,6 +11,12 @@ #include "elfconfig.h" +/* Cygwin's elf.h defines these according to host's word size */ +#undef ELF_ST_BIND +#undef ELF_ST_TYPE +#undef ELF_R_SYM +#undef ELF_R_TYPE + #if KERNEL_ELFCLASS == ELFCLASS32 #define Elf_EhdrElf32_Ehdr -- 1.9.5.msysgit.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/ -- 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 1/7] KVM: api: add kvm_irq_routing_extended_msi
Hello!
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of Eric Auger
> Sent: Monday, June 29, 2015 6:37 PM
> To: eric.au...@st.com; eric.au...@linaro.org;
> linux-arm-ker...@lists.infradead.org;
> marc.zyng...@arm.com; christoffer.d...@linaro.org; andre.przyw...@arm.com;
> kvm...@lists.cs.columbia.edu; k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com;
> pbonz...@redhat.com
> Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
>
> On ARM, the MSI msg (address and data) comes along with
> out-of-band device ID information. The device ID encodes the device
> that composes the MSI msg. Let's create a new routing entry type,
> dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
> to convey the device ID.
>
> Signed-off-by: Eric Auger
>
> ---
>
> RFC -> PATCH
> - remove kvm_irq_routing_extended_msi and use union instead
> ---
> Documentation/virtual/kvm/api.txt | 9 -
> include/uapi/linux/kvm.h | 6 +-
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index d20fd94..6426ae9 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1414,7 +1414,10 @@ struct kvm_irq_routing_entry {
> __u32 gsi;
> __u32 type;
> __u32 flags;
> - __u32 pad;
> + union {
> + __u32 pad;
> + __u32 devid;
> + };
> union {
> struct kvm_irq_routing_irqchip irqchip;
> struct kvm_irq_routing_msi msi;
devid is actually a part of MSI bunch. Shouldn't it be a part of struct
kvm_irq_routing_msi then?
It also has reserved pad.
> @@ -1427,6 +1430,10 @@ struct kvm_irq_routing_entry {
> #define KVM_IRQ_ROUTING_IRQCHIP 1
> #define KVM_IRQ_ROUTING_MSI 2
> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
> +
> +In case of KVM_IRQ_ROUTING_EXTENDED_MSI routing type, devid is used to convey
> +the device ID.
>
> No flags are specified so far, the corresponding field must be set to zero.
What if we use KVM_MSI_VALID_DEVID flag instead of new
KVM_IRQ_ROUTING_EXTENDED_MSI definition? I
believe this would make an API more consistent and introduce less new
definitions.
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 2a23705..8484681 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -841,12 +841,16 @@ struct kvm_irq_routing_s390_adapter {
> #define KVM_IRQ_ROUTING_IRQCHIP 1
> #define KVM_IRQ_ROUTING_MSI 2
> #define KVM_IRQ_ROUTING_S390_ADAPTER 3
> +#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
>
> struct kvm_irq_routing_entry {
> __u32 gsi;
> __u32 type;
> __u32 flags;
> - __u32 pad;
> + union {
> + __u32 pad;
> + __u32 devid;
> + };
> union {
> struct kvm_irq_routing_irqchip irqchip;
> struct kvm_irq_routing_msi msi;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping
Hello! > -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf > Of Eric Auger > Sent: Monday, June 29, 2015 6:37 PM > To: eric.au...@st.com; eric.au...@linaro.org; > linux-arm-ker...@lists.infradead.org; > marc.zyng...@arm.com; christoffer.d...@linaro.org; andre.przyw...@arm.com; > kvm...@lists.cs.columbia.edu; k...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com; > pbonz...@redhat.com > Subject: [PATCH 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping > > If the ITS modality is not available, let's simply support MSI > injection by transforming the MSI.data into an SPI ID. > > This becomes possible to use KVM_SIGNAL_MSI ioctl for arm too. > > Signed-off-by: Eric Auger > --- > arch/arm/kvm/Kconfig | 1 + > virt/kvm/arm/vgic.c | 5 + > 2 files changed, 6 insertions(+) > > diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig > index 151e710..0f58baf 100644 > --- a/arch/arm/kvm/Kconfig > +++ b/arch/arm/kvm/Kconfig > @@ -31,6 +31,7 @@ config KVM > select KVM_VFIO > select HAVE_KVM_EVENTFD > select HAVE_KVM_IRQFD > + select HAVE_KVM_MSI > select HAVE_KVM_IRQCHIP > select HAVE_KVM_IRQ_ROUTING > depends on ARM_VIRT_EXT && ARM_LPAE && ARM_ARCH_TIMER > diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c > index 0b4c48c..b3c10dc 100644 > --- a/virt/kvm/arm/vgic.c > +++ b/virt/kvm/arm/vgic.c > @@ -2314,6 +2314,11 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e, > return kvm->arch.vgic.vm_ops.inject_msi(kvm, &msi); > else > return -ENODEV; > + case KVM_IRQ_ROUTING_MSI: > + if (kvm->arch.vgic.vm_ops.inject_msi) > + return -EINVAL; > + else > + return kvm_vgic_inject_irq(kvm, 0, e->msi.data, level); Given API change i suggest (using KVM_MSI_VALID_DEVID flag), we could get rid of all these if()'s here. Just forward all parameters to vGIC implementation code and let it do its checks. > default: > return -EINVAL; > } > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 1/7] KVM: api: add kvm_irq_routing_extended_msi
Hello! > What if we use KVM_MSI_VALID_DEVID flag instead of new > KVM_IRQ_ROUTING_EXTENDED_MSI > definition? I > believe this would make an API more consistent and introduce less new > definitions. I have just found one more flaw in your implementation. If you take a look at irqfd_wakeup()... --- cut --- /* An event has been signaled, inject an interrupt */ if (irq.type == KVM_IRQ_ROUTING_MSI) kvm_set_msi(&irq, kvm, KVM_USERSPACE_IRQ_SOURCE_ID, 1, false); else schedule_work(&irqfd->inject); --- cut --- You apparently missed KVM_IRQ_ROUTING_EXTENDED_MSI here, as well as in irqfd_update(). But, if you accept my API proposal, this becomes irrelevant. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping
Hello! > > Given API change i suggest (using KVM_MSI_VALID_DEVID flag), we could get > > rid of all these if()'s > > here. Just forward all parameters to vGIC implementation code and let it do > > its checks. > I don't understand this comment. Here this is the kernel struct that is > used (struct kvm_kernel_irq_routing_entry) and not the user one > (kvm_irq_routing_entry). The kernel struct does not have the flag field. Easy. ARM code can always use struct kvm_extended_msi, and flags can go to this structure. > Another reason I think to keep using the type for homogeneity. Homogeneity is perfect IMHO. If that would be simpler for you, i could post a patch for this which i made on top of your series. Sorry, i don't have time to respin the whole thing, busy with qemu GICv3 fight :) Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 1/7] KVM: api: add kvm_irq_routing_extended_msi
Hello! > OK thanks for sharing. I need some more time to study qemu code too. I am currently working on supporting this in qemu. Not ready yet, need some time. But, with API i suggest, things are really much-much simpler. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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/
PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello! So, what should we do with this?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Pavel
> Fedin
> Sent: Monday, November 02, 2015 10:19 AM
> To: 'David Miller'
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> steve.glendinn...@shawell.net
> Subject: RE: [PATCH] net: smsc911x: Reset PHY during initialization
>
> Hello!
>
> > > On certain hardware after software reboot the chip may get stuck and fail
> > > to reinitialize during reset. This can be fixed by ensuring that PHY is
> > > reset too.
> > >
> > > Old PHY resetting method required operational MDIO interface, therefore
> > > the chip should have been already set up. In order to be able to function
> > > during probe, it is changed to use PMT_CTRL register.
> > >
> > > The problem could be observed on SMDK5410 board.
> > >
> > > Signed-off-by: Pavel Fedin
> >
> > I'm pretty sure this is going to break the PHY loopback test.
>
> It's not (at least in normal situation), because first we do the test, and
> only then, if it
> fails, we reset the PHY. So, during
> normal operation of the driver, when loopback test succeeds at first attempt,
> we never attempt
> to reset the PHY. And, by the way, at
> least on my board this PHY reset did nothing useful, because after it
> loopback test still
> failed, all 100 times.
> And, we don't use PHY reset anywhere outside of loopback test.
>
> > This is such a tricky and fragile area to get right, therefore I
> > want you to specifically guard any change in how PHY reset is
> > done with tests against the specific chips that have the problem.
>
> Well, i could do one (or some combination) of the following, if you really
> want to:
> a) Leave PHY reset inside loopback test as it is, but add a second routine
> and call it only
> before smsc911x_soft_reset().
> b) Reset PHY only conditionally, using the following algorithm:
> if smsc911x_soft_reset() {
> /* NIC reset failed, kick the PHY and retry */
> smsc911x_phy_reset()
> if (smsc_911x_soft_reset())
> return -ENODEV;
> }
> c) Do extra PHY reset only if some hint in device tree is specified (or the
> machine is known
> to have the problem)
>
> But, i dislike approach (a) for code duplication, because datasheet says
> that both reset
> methods are equivalent; i dislike approach
> (b) for actually being a hack; and i dislike (c) for adding extra stuff which
> seems to be not
> necessary. After all, what is wrong
> with just extra PHY reset before attempting to program anything? By the way,
> i test my patch
> with both software reboot and hardware
> reboot, and even powercycle. Everything is quite stable.
> Well, it's up to you to decide. But i'd like to get the fix upstreamed
> somehow because from
> time to time we use these boards for
> tests, and it's quite annoiying to be unable to reboot them properly.
>
> > Furthermore, I want you to test whether this has any negative
> > effects on the PHY loopback test.
>
> I did. I never disabled loopback test, so i actually discovered a problem
> (even two) with it.
> First, the problem was chip reset
> timeout. By increasing it to 300ms this problem seemed to be fixed, but
> loopback test started
> to fail. This was how i found and
> fixed crash with missing phy_disconnect(). I examined the code and discovered
> that upon
> loopback test failure we reset the PHY and
> retry. But in my case this PHY reset never did the right thing, and all
> loopback attempts
> (10x10 IIRC) were failing.
> Some comments in the code gave me a clue that the main NIC can misbehave on
> reset if e.g. PHY
> is in powerdown state. I printed
> value of its control register and discovered that it was not the case. But
> then i discovered
> that we actually never try to reset the
> PHY before doing anything. Also, while studying the datasheed i discovered
> that there is a
> shorthand for resetting PHY without MDIO
> bus set up, but our driver doesn't use it, preferring MDIO method instead,
> which already
> requires operational NIC.
> So, i suggested that PHY is just not being reset when board is rebooted by
> software. I wrote
> the patch and it worked. I verified it
> by reverting my previous NIC reset timeout increase, and it continued to
> work. After this
> loopback test on my board passes at first
> attempt.
>
> Kind regards,
&
RE: [PATCH v7 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos,
> > Tacs.
> > +Each value is specified in cycles and has the
> > following
> > +meaning and valid range:
> > +Tacp : Page mode access cycle at Page mode (0 - 15)
> > +Tcah : Address holding time after CSn (0 - 15)
> > +Tcoh : Chip selection hold on OEn (0 - 15)
> > +Tacc : Access cycle (0 - 31, the actual time is N
> > + 1)
> > +Tcos : Chip selection set-up before OEn (0 - 15)
> > +Tacs : Address set-up before CSn (0 - 15)
>
> This is not easily extended. Perhaps a property per value instead.
We had a discussion with Krzysztof about it, he agreed with this form of the
property.
My concern was that it's just too much typing, and makes little sense because
these
settings always go together. If register layout changes, or parameter set
changes in
incompatible way, then it's another device, not exynos-srom anymore.
So would you agree with that, or is your position strong?
> > compatible = "samsung,exynos-srom";
> > - reg = <0x1257 0x10>;
> > + reg = <0x1257 0x14>;
> > +
> > + ethernet@3 {
> > + compatible = "smsc,lan9115";
> > + reg = <3 0 0x1>; // Bank 3, offset = 0
> > + phy-mode = "mii";
> > + interrupt-parent = <&gpx0>;
> > + interrupts = <5 8>;
> > + reg-io-width = <2>;
> > + smsc,irq-push-pull;
> > + smsc,force-internal-phy;
> > +
> > + samsung,srom-config = <1 9 12 1 9 1 1>;
>
> This doesn't match the doc.
Damn, overlooked. :(
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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: PING: [PATCH] net: smsc911x: Reset PHY during initialization
Hello!
> If you think I should reconsider the patch, you should resubmit it.
I understand this, of course. But, before doing this i'd like to
clarify your concern, why exactly you think that loopback test will
break. Because the (simplified) algorithm is:
do {
result = loopback_test()
if (result == failed)
reset_phy()
} while (result == ok)
So, if loopback test works for the first time, PHY reset will never
be done. So, the conclusion is: in real situation it is never used at all.
Conclusion no 2, coming from my tests: if loopback test fails, phy reset
actually does not fix it. So, perhaps, it's not needed there at all.
I understand, that some other boards might behave differently, and loopback
test was written this very way for some reason. Also, i
understand that you, as a maintainer, have rights for the final decision. And
in order to rework the patch, i'd like to discuss with
you, which rework you would prefer. I came up with three possibilities:
--- cut ---
a) Leave PHY reset inside loopback test as it is, but add a second routine and
call it only before smsc911x_soft_reset().
b) Reset PHY only conditionally, using the following algorithm:
if smsc911x_soft_reset() {
/* NIC reset failed, kick the PHY and retry */
smsc911x_phy_reset()
if (smsc_911x_soft_reset())
return -ENODEV;
}
c) Do extra PHY reset only if some hint in device tree is specified (or the
machine is known to have the problem)
--- cut ---
I can even try to guess your thoughts (because you never elaborated them for
me):
1. loopback test will break because PHY has been reset before. In this case,
(b) or (c) is a way to go.
2. loopback test will break because of reset method change. In this case (a)
is the way to go.
So, what do you really think?
BTW, where is Steve, whose address is specified in MAINTAINERS for this code?
Is it abandonware?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.
With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.
This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.
v8 => v9:
- Fixed node suffix in ethernet chip DT node (@3,0 instead of @3)
v7 => v8:
- More fixes to documentation
v6 => v7:
- Fixed stupid error in Tacc description in the documentation
v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
constant name for interrupt config byte)
v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
"reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation
v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
to cleary specify dependency. If configuration fails, error will be reported
and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.
v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now
v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation
Pavel Fedin (4):
Documentation: dt-bindings: Describe SROMc configuration
ARM: dts: Add SROMc to Exynos 5410
drivers: exynos-srom: Add support for bank configuration
ARM: dts: Add Ethernet chip to SMDK5410
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41
arch/arm/boot/dts/exynos5410.dtsi | 11
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig| 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +-
6 files changed, 184 insertions(+), 6 deletions(-)
--
2.4.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/
[PATCH v9 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
arch/arm/boot/dts/exynos5410.dtsi | 6 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..a731fbe 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5410.dtsi"
+#include
/ {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410",
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@3,0 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
pmu_system_controller: system-controller@1004 {
--
2.4.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/
[PATCH v9 1/4] Documentation: dt-bindings: Describe SROMc configuration
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.
Also, fix size of SROMc mapping in the example.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
Acked-by: Rob Herring
---
.../bindings/arm/samsung/exynos-srom.txt | 73 +-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..e5c18df 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
- reg: offset and length of the register set
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+ the memory mapped for the device. Note that base address will be
+ typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+ 0 - normal (one data)
+ 1 - four data
+ If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+ sromc@1257 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x0400 0x2 // Bank0
+ 1 0 0x0500 0x2 // Bank1
+ 2 0 0x0600 0x2 // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+
+ ethernet@3,0 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>; // Bank 3, offset = 0
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
};
--
2.4.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/
[PATCH v9 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
--
2.4.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/
[PATCH v9 3/4] drivers: exynos-srom: Add support for bank configuration
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.
Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.
Signed-off-by: Pavel Fedin
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/mach-exynos/Kconfig | 2 +-
drivers/soc/samsung/Kconfig | 2 +-
drivers/soc/samsung/exynos-srom.c | 61 +--
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
- select EXYNOS_SROM if PM
+ select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
config EXYNOS_SROM
bool
- depends on ARM && ARCH_EXYNOS && PM
+ depends on ARM && ARCH_EXYNOS
endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump
*exynos_srom_alloc_reg_dump(
return rd;
}
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+ u32 bank, width, pmc;
+ u32 timing[6];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "reg", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "reg-io-width", &width))
+ width = 1;
+ if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+ pmc = 0;
+ if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+ ARRAY_SIZE(timing)))
+ return -EINVAL;
+
+ bank *= 4; /* Convert bank into shift/offset */
+
+ cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+ if (width == 2)
+ cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+ bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+ bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+ __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+ __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+ srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+ return 0;
+}
+
static int exynos_srom_probe(struct platform_device *pdev)
{
- struct device_node *np;
+ struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+ bool bad_bank_config = false;
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
- return 0;
+ for_each_child_of_node(np, child) {
+ if (exynos_srom_configure_bank(srom, child)) {
+ dev_err(dev,
+ "Could not decode bank configuration for %s\n",
+ child->name);
+ bad_bank_config = true;
+ }
+ }
+
+ /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+ if (bad_bank_config)
+ return 0;
+
+ return of_platform_populate(np, NULL, NULL, dev);
}
static int exynos_srom_remove(struct platform_device *pdev)
--
2.4.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 v4 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> >>> --- cut exynos5410.dtsi ---
> >>> sromc: sromc@1225 {
> >>> #address-cells = <2>;
> >>> #size-cells = <1>;
> >>> ranges = <0 0 0x0400 0x2
> >>> 1 0 0x0500 0x2
> >>> 2 0 0x0600 0x2
> >>> 3 0 0x0700 0x2>;
> >>
> >> Do you have to use 2 cells for address? Cannot it be:
> >>ranges = <0 0x0400 0x2
> >> 1 0x0500 0x2
> >> 2 0x0600 0x2
> >> 3 0x0700 0x2>;
> >
> > I tried this first, but it didn't work, and ranges translation
> > gave me something really weird (like addr = 0x80 and
> > size = 0x0404).
>
> Did you change the address-cells to <1>?
Of course i did.
I don't quote the rest because i simply agree to what you've said. Will respin
with these changes.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 v5 4/4] ARM: dts: Add Ethernet chip to SMDK5410
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410-smdk5410.dts | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..f41952f 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -61,6 +61,27 @@
disable-wp;
};
+&pinctrl_0 {
+ srom_ctl: srom-ctl {
+ samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+ "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-drv = <0>;
+ };
+
+ srom_ebi: srom-ebi {
+ samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+ "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+ "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+ "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+ "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+ "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
+
&uart0 {
status = "okay";
};
@@ -72,3 +93,22 @@
&uart2 {
status = "okay";
};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@3 {
+ compatible = "smsc,lan9115";
+ reg = <3 0 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-page-mode = <1>;
+ samsung,srom-timing = <9 12 1 9 1 1>;
+ };
+};
--
2.4.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/
