From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca>, <linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART Date: Mon, 7 Jan 2013 19:34:35 +0530 [thread overview] Message-ID: <50EAD5F3.7030204@synopsys.com> (raw) In-Reply-To: <201301071346.01620.arnd@arndb.de> On Monday 07 January 2013 07:16 PM, Arnd Bergmann wrote: > On Monday 07 January 2013, Vineet Gupta wrote: >> On Wednesday 07 November 2012 07:46 PM, Arnd Bergmann wrote: >>> On Wednesday 07 November 2012, Vineet Gupta wrote: >> (1) Although I don't need the container "fpga" I'm forced to - because >> of_platform_populate( ) -> of_match_node( ) expects the @match arg to be NOT NULL. >> So we pass of_default_bus_match_table and have the compat string "simple-bus" in >> the container. Per [1] it seemed it was possible to add the serial device directly >> w/o the container. > You could in theory make the serial port device itself be compatible to > somthing that is being probed by of_platform_populate, but putting it > under a bus is the preferred way. Usually each system has at least one > bus that devices are connected to and I would recommend to represent all > buses in the device tree like they are in hardware. OK. >> (2) I need the following OF_DEV_AUXDATA to be able to "name" the device correctly >> so that the registered driver [4] can bind with device. How do I match the driver >> and devicetree node w/o this glue - it seems compatible="<manuf>,<model>" is not >> enough. This also requires the uart base address to be specified (otherwise >> of_dev_lookup() fails to identify the auxdata) which IMHO defeats the purpose of >> devicetree in first place. >> b >> static struct of_dev_auxdata arcuart_auxdata_lookup[] __initdata = { >> OF_DEV_AUXDATA("snps,arc-uart", UART0_BASE, "arc-uart", arc_uart_info), >> {} >> }; > It should be enough to fill the drv->of_match_table member of the > platform_driver with the match table. Not sure if I understand. My concern is the #define UART0_BASE (=0xc0fc1000) which needs to be defined in code despite that value being present in the device tree. And this is needed so that framework could match the device against the driver. I would have thought that some device property (in device tree) could enable the matching with Linux name (actually DRIVER_NAME defined in the uart driver). Am I missing something ? >> (3) After above, driver's probe routine is getting called with platform_device->id >> = -1 and it seems of_device_add() is doing that purposely. How do I handle that. > What do you need the id for? In case of multiple instances of UART, driver uses this value to index into struct arc_uart_port [ ] struct arc_uart_port { struct uart_port port; unsigned long baud; int is_emulated; }; static struct arc_uart_port arc_uart_ports[CONFIG_SERIAL_ARC_NR_PORTS]; arc_serial_probe(struct platform_device *pdev) uart = &arc_uart_ports[pdev->id]; arc_uart_init_one(pdev, ..) if (pdev->id < 0 ...) return -ENOENT; Although the current driver is flawed in that it checks for -ve value after already indexing into the array :-( I'll send a patch to serial list to fix that. >> (4) Is above standalone "interrupts" string OK, or do I have to explicitly >> instantiate the in-core intc as well. Since it is integral part of cpu, I really >> don't need any support code to explicitly instantiate it. Also it is not accessed >> via mem map - but special ARC instructions in aux address space of cpu. > Interrupts are a little tricky. You need to create a bindind for your interrupt > controller first and make the irqchip driver use irq domains in order for the > irq description in the device tree to be mapped into a linux-internal irq number. > > In the simple case where you only have one irqchip in the system, you can use > a "legacy" irq domain that simply translates the numbers 1:1. In some cases, > it does make sense though (even with the legacy domain) to include additional > flags in the device tree irq descriptor, e.g. the irq polarity and > edge/level/message indication. Please read up on these and ask again if you have > more questions. Will do. Thx, -Vineet > > Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca>, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART Date: Mon, 7 Jan 2013 19:34:35 +0530 [thread overview] Message-ID: <50EAD5F3.7030204@synopsys.com> (raw) In-Reply-To: <201301071346.01620.arnd@arndb.de> On Monday 07 January 2013 07:16 PM, Arnd Bergmann wrote: > On Monday 07 January 2013, Vineet Gupta wrote: >> On Wednesday 07 November 2012 07:46 PM, Arnd Bergmann wrote: >>> On Wednesday 07 November 2012, Vineet Gupta wrote: >> (1) Although I don't need the container "fpga" I'm forced to - because >> of_platform_populate( ) -> of_match_node( ) expects the @match arg to be NOT NULL. >> So we pass of_default_bus_match_table and have the compat string "simple-bus" in >> the container. Per [1] it seemed it was possible to add the serial device directly >> w/o the container. > You could in theory make the serial port device itself be compatible to > somthing that is being probed by of_platform_populate, but putting it > under a bus is the preferred way. Usually each system has at least one > bus that devices are connected to and I would recommend to represent all > buses in the device tree like they are in hardware. OK. >> (2) I need the following OF_DEV_AUXDATA to be able to "name" the device correctly >> so that the registered driver [4] can bind with device. How do I match the driver >> and devicetree node w/o this glue - it seems compatible="<manuf>,<model>" is not >> enough. This also requires the uart base address to be specified (otherwise >> of_dev_lookup() fails to identify the auxdata) which IMHO defeats the purpose of >> devicetree in first place. >> b >> static struct of_dev_auxdata arcuart_auxdata_lookup[] __initdata = { >> OF_DEV_AUXDATA("snps,arc-uart", UART0_BASE, "arc-uart", arc_uart_info), >> {} >> }; > It should be enough to fill the drv->of_match_table member of the > platform_driver with the match table. Not sure if I understand. My concern is the #define UART0_BASE (=0xc0fc1000) which needs to be defined in code despite that value being present in the device tree. And this is needed so that framework could match the device against the driver. I would have thought that some device property (in device tree) could enable the matching with Linux name (actually DRIVER_NAME defined in the uart driver). Am I missing something ? >> (3) After above, driver's probe routine is getting called with platform_device->id >> = -1 and it seems of_device_add() is doing that purposely. How do I handle that. > What do you need the id for? In case of multiple instances of UART, driver uses this value to index into struct arc_uart_port [ ] struct arc_uart_port { struct uart_port port; unsigned long baud; int is_emulated; }; static struct arc_uart_port arc_uart_ports[CONFIG_SERIAL_ARC_NR_PORTS]; arc_serial_probe(struct platform_device *pdev) uart = &arc_uart_ports[pdev->id]; arc_uart_init_one(pdev, ..) if (pdev->id < 0 ...) return -ENOENT; Although the current driver is flawed in that it checks for -ve value after already indexing into the array :-( I'll send a patch to serial list to fix that. >> (4) Is above standalone "interrupts" string OK, or do I have to explicitly >> instantiate the in-core intc as well. Since it is integral part of cpu, I really >> don't need any support code to explicitly instantiate it. Also it is not accessed >> via mem map - but special ARC instructions in aux address space of cpu. > Interrupts are a little tricky. You need to create a bindind for your interrupt > controller first and make the irqchip driver use irq domains in order for the > irq description in the device tree to be mapped into a linux-internal irq number. > > In the simple case where you only have one irqchip in the system, you can use > a "legacy" irq domain that simply translates the numbers 1:1. In some cases, > it does make sense though (even with the legacy domain) to include additional > flags in the device tree irq descriptor, e.g. the irq polarity and > edge/level/message indication. Please read up on these and ask again if you have > more questions. Will do. Thx, -Vineet > > Arnd
next prev parent reply other threads:[~2013-01-07 14:05 UTC|newest] Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-07 9:47 [RFC Patch v1 00/31] Synopsys ARC Linux kernel Port Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 01/31] ARC: Generic Headers Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 02/31] ARC: irqflags Vineet Gupta 2012-11-12 19:50 ` Thomas Gleixner 2013-01-01 7:44 ` Vineet Gupta 2013-01-01 7:44 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 03/31] ARC: atomic/bitops/cmpxchg/barriers Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 04/31] asm-generic headers: uaccess.h to conditionally define segment_eq() Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 05/31] ARC: uaccess friends Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 06/31] asm-generic headers: Allow yet more arch overrides in checksum.h Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 07/31] ARC: checksum/byteorder/swab routines Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 08/31] ARC: Fundamental ARCH data-types/defines Vineet Gupta 2012-11-08 7:10 ` Jonas Bonn 2012-11-08 18:52 ` Vineet Gupta 2012-11-08 20:36 ` Jonas Bonn 2012-11-12 13:58 ` Vineet Gupta 2012-11-12 14:12 ` Arnd Bergmann 2012-11-07 9:47 ` [RFC PATCH v1 09/31] ARC: spinlock/rwlock/mutex primitives Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 10/31] ARC: string library Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 11/31] ARC: Low level IRQ/Trap/Exception(non-MMU) Handling Vineet Gupta 2012-11-16 4:58 ` Al Viro 2012-12-27 9:00 ` Vineet Gupta 2012-12-27 9:00 ` Vineet Gupta 2012-12-27 13:29 ` Vineet Gupta 2012-12-27 13:29 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 12/31] ARC: Interrupt Handling Vineet Gupta 2012-11-12 20:08 ` Thomas Gleixner 2013-01-01 10:46 ` Vineet Gupta 2013-01-01 10:46 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 13/31] ARC: Non-MMU Exception Handling Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 14/31] ARC: syscall support Vineet Gupta 2012-11-07 14:21 ` Arnd Bergmann 2012-11-09 9:50 ` James Hogan 2012-11-09 9:50 ` James Hogan 2012-11-13 11:41 ` James Hogan 2012-11-13 11:41 ` James Hogan 2012-11-13 12:01 ` Jonas Bonn 2012-11-13 12:11 ` James Hogan 2012-11-13 12:11 ` James Hogan 2012-11-14 12:23 ` Arnd Bergmann 2012-11-14 12:31 ` James Hogan 2012-11-14 12:31 ` James Hogan 2012-11-13 10:13 ` Gilad Ben-Yossef 2012-11-13 10:37 ` Arnd Bergmann 2012-11-15 6:15 ` Vineet Gupta 2012-11-15 6:15 ` Vineet Gupta 2012-11-15 12:35 ` Arnd Bergmann 2013-01-17 5:13 ` Vineet Gupta 2013-01-17 5:13 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 15/31] ARC: Process/scheduling/clock/Timers/Delay Management Vineet Gupta 2012-11-12 20:29 ` Thomas Gleixner 2013-01-02 7:13 ` Vineet Gupta 2013-01-02 7:13 ` Vineet Gupta 2013-01-02 8:45 ` Vineet Gupta 2013-01-02 8:45 ` Vineet Gupta 2013-01-04 13:01 ` Frederic Weisbecker 2012-11-07 9:47 ` [RFC PATCH v1 16/31] ARC: Signal handling Vineet Gupta 2012-11-16 5:26 ` Al Viro 2012-12-28 12:34 ` Vineet Gupta 2012-12-28 12:34 ` Vineet Gupta 2012-12-28 12:42 ` [PATCH 1/2] ARC: [Review] Preparing to fix incorrect syscall restarts due to signals Vineet Gupta 2012-12-28 12:42 ` Vineet Gupta 2012-12-28 12:42 ` [PATCH 2/2] ARC: [Review] Prevent incorrect syscall restarts Vineet Gupta 2012-12-28 12:42 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 17/31] ARC: Cache Flush Management Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 18/31] ARC: Page Table Management Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 19/31] ARC: MMU Context Management Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 20/31] ARC: MMU Exception Handling Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 21/31] ARC: TLB flush Handling Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 22/31] ARC: Page Fault handling (incl uaccess fixup) Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 23/31] ARC: I/O and DMA Mappings Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 24/31] ARC: startup #1: low-level, setup_arch(), /proc/cpuinfo, mem init Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART Vineet Gupta 2012-11-07 14:16 ` Arnd Bergmann 2013-01-07 13:10 ` Vineet Gupta 2013-01-07 13:10 ` Vineet Gupta 2013-01-07 13:46 ` Arnd Bergmann 2013-01-07 14:04 ` Vineet Gupta [this message] 2013-01-07 14:04 ` Vineet Gupta 2013-01-07 14:36 ` Arnd Bergmann 2013-01-14 7:35 ` early init dt for earlyprintk (was Re: [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART) Vineet Gupta 2013-01-14 7:35 ` Vineet Gupta 2013-01-14 9:48 ` James Hogan 2013-01-14 9:48 ` James Hogan 2013-01-14 10:09 ` Vineet Gupta 2013-01-14 10:09 ` Vineet Gupta 2013-01-14 10:54 ` Arnd Bergmann 2013-01-17 7:29 ` [RFC PATCH v1 25/31] ARC: [plat-arcfpga] Hooking up platform to ARC UART Vineet Gupta 2013-01-17 7:29 ` Vineet Gupta 2013-01-17 10:52 ` Arnd Bergmann 2012-11-07 9:47 ` [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script Vineet Gupta 2012-11-07 14:13 ` Arnd Bergmann 2013-01-02 14:30 ` Vineet Gupta 2013-01-02 14:48 ` Arnd Bergmann 2013-01-03 7:58 ` Vineet Gupta 2013-01-03 7:58 ` Vineet Gupta 2013-01-03 8:25 ` Arnd Bergmann 2013-03-11 12:29 ` SYSV IPC broken for no-legacy syscall kernels (was Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script) Vineet Gupta 2013-03-11 12:29 ` Vineet Gupta 2013-03-11 12:44 ` James Hogan 2013-03-11 12:44 ` James Hogan 2013-03-11 12:56 ` Vineet Gupta 2013-03-11 12:56 ` Vineet Gupta 2013-03-11 13:07 ` James Hogan 2013-03-11 13:07 ` James Hogan 2013-03-11 13:30 ` Arnd Bergmann 2013-03-11 13:48 ` Vineet Gupta 2013-03-11 13:48 ` Vineet Gupta 2013-03-11 14:50 ` Arnd Bergmann 2012-11-15 17:49 ` [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script James Hogan 2012-11-15 17:49 ` James Hogan 2012-11-15 19:30 ` Ralf Baechle 2012-11-16 6:36 ` Vineet Gupta 2012-11-16 6:36 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 27/31] ARC: Last bits (stubs) to get to a running kernel with UART Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 28/31] ARC: split ret_from_fork, simplify kernel_thread() Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 29/31] ARC: switch to generic kernel_thread() Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 30/31] ARC: switch to generic kernel_execve() and sys_execve() Vineet Gupta 2012-11-16 4:08 ` Al Viro 2012-11-17 14:01 ` Vineet Gupta 2012-11-17 14:01 ` Vineet Gupta 2012-11-07 9:47 ` [RFC PATCH v1 31/31] ARC: [plat-arcfpga] defconfig Vineet Gupta 2012-11-07 14:06 ` Arnd Bergmann 2012-11-12 14:18 ` James Hogan 2012-11-12 14:18 ` James Hogan 2012-11-12 14:21 ` Arnd Bergmann 2012-11-07 14:36 ` [RFC Patch v1 00/31] Synopsys ARC Linux kernel Port Arnd Bergmann 2012-11-08 19:09 ` Vineet Gupta 2012-11-07 20:46 ` Gilad Ben-Yossef 2012-11-20 13:47 ` Pavel Machek 2012-11-20 13:49 ` Vineet Gupta 2012-11-20 13:49 ` Vineet Gupta 2012-11-20 13:59 ` Pavel Machek 2012-11-20 14:17 ` Vineet Gupta 2012-11-20 14:17 ` Vineet Gupta 2013-01-18 19:46 ` Pavel Machek 2013-01-18 22:17 ` Arnd Bergmann 2013-01-19 10:15 ` Pavel Machek 2013-01-19 12:32 ` Vineet Gupta 2013-01-19 12:32 ` Vineet Gupta 2013-01-19 17:02 ` Pavel Machek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=50EAD5F3.7030204@synopsys.com \ --to=vineet.gupta1@synopsys.com \ --cc=arnd@arndb.de \ --cc=grant.likely@secretlab.ca \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.