usb gadget serial changes since 2.6.14
Hi, I'm having trouble porting our in-house UDC driver to 2.6.27. It originally worked on 2.6.14 as an CDC-ACM driver. I notice a lot of changes since 2.6.14. For starters, instead of the single serial.c file, there is now f_serial.c, u_serial.c and f_acm.c. Currently, the UDC driver in 2.6.27 seems to work if I simply plug the USB cable in between our gadget serial Linux device and a Windows PC. However, if I unplug, then replug the cable, the 'Out' Endpoint seems fine, but the 'In' Endpoint doesn't seem to come up properly. In other words, data only seems to be getting through in the direction from the PC to the gadget serial Linux device, but not vice versa. Is there some sort of architecture document to show how the f_serial.c, u_serial.c and f_acm.c files all fit together? I've searched in the Documentation directory and I've read the usb-gadget-serial docbook document but it doesn't really tell me this. Also, it seems that for some reason composite.c is being compiled and used, but my CDC-ACM gadget serial driver is *not* a composite driver. Is it possible to prevent linking with this composite driver? Cheers, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 09:26:02PM -0700, H. Peter Anvin wrote: I2C or similar busses can be a particularly annoying if they contain essential configuration information such as memory size which is needed long before anything else. So for far a common solution is that platforms are carrying a private (aka redundant, ugly) early-i2c system that's just about sufficient for this purpose. For what it's worth, this is true for pretty much ALL systems with removable memory modules, since Serial Presence Detect (SPD) is electrically equivalent to I2C. However, on most systems, even embedded, bringing up memory falls on firmware (sometimes in the form of a boot loader) so Linux rarely sees it. There are embedded systems were the firmware does not provide a usuable memory map or where that is plain broken. Or Linux with some extra init code serves as the firmware. Often there is a single serial EEPROM for the entire system. If there is an atrocity that can save a penny it will be commited at least in the embedded world. Ralf -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. - k -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH 14/14] Pramfs: XIP Operations
Jared Hulbert wrote: I know. It wasn't my intention to introduce it but as I said in my first patch I've done a porting of this code from 2.6.10 and to remove it I need time to analyze well the code to avoid deadlock and so on. If someone would like to help me I'd really appreciate it. However I see the use of BKL even in other recent mainlined fs as ext4, so I preferred to move the porting effort on other areas. However it's the first item on my todo list. Why do you need the lock in pram_find_and_alloc_blocks() to begin with? Why wouldn't a mutex work? It's not impossible to use a mutex, but as I said it's inherited from code written for 2.6.10. This function works as pram_get_and_update_block works. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write Protection
Jared Hulbert wrote:
+/* init_mm.page_table_lock must be held before calling! */
+static void pram_page_writeable(unsigned long addr, int rw)
+{
+ ? ? ? pgd_t *pgdp;
+ ? ? ? pud_t *pudp;
+ ? ? ? pmd_t *pmdp;
+ ? ? ? pte_t *ptep;
+
+ ? ? ? pgdp = pgd_offset_k(addr);
+ ? ? ? if (!pgd_none(*pgdp)) {
+ ? ? ? ? ? ? ? pudp = pud_offset(pgdp, addr);
+ ? ? ? ? ? ? ? if (!pud_none(*pudp)) {
+ ? ? ? ? ? ? ? ? ? ? ? pmdp = pmd_offset(pudp, addr);
+ ? ? ? ? ? ? ? ? ? ? ? if (!pmd_none(*pmdp)) {
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_t pte;
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ptep = pte_offset_kernel(pmdp, addr);
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = *ptep;
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (pte_present(pte)) {
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = rw ? pte_mkwrite(pte) :
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_wrprotect(pte);
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set_pte(ptep, pte);
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
+ ? ? ? ? ? ? ? ? ? ? ? }
+ ? ? ? ? ? ? ? }
+ ? ? ? }
+}
Wow. Don't we want to do this pte walking in mm/ someplace?
Do you really intend to protect just the PTE in question rather than
the entire physical page, regardless of which PTE is talking to it?
Maybe I'm missing something.
follow_pfn() ought to be fine for this, optionally follow_pte() could be
exported and used.
Ok I can create a new exported function follow_pte().
+#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300)
|| \
+ ? ? ? defined(CONFIG_BLACKFIN)
+ ? ? ? /*
+ ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(),
+ ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal
+ ? ? ? ?* to use _range() because many archs just flush the whole TLB.
+ ? ? ? ?*/
+ ? ? ? if (end = start + PAGE_SIZE)
+ ? ? ? ? ? ? ? flush_tlb_kernel_page(start);
+ ? ? ? else
+#endif
+ ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end);
+}
Why not just fix flush_tlb_range()?
If an arch has a flush_tlb_kernel_page() that works then it stands to
reason that the flush_tlb_kernel_range() shouldn't work with minimal
effort, no?
flush_tlb_kernel_page() is a new one to me, it doesn't have any mention
in Documentation/cachetlb.txt anyways.
Many of the flush_tlb_kernel_range() implementations do ranged checks
with tunables to determine whether it is more expensive to selectively
flush vs just blowing the entire TLB away.
Likewise, there is no reason why those 4 architectures can not just shove
that if (end = start + PAGE_SIZE) check in the beginning of their
flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for
those cases. Hiding this in generic code is definitely not the way to go.
Ok I'll change that function at arch level and I'll remove the ifdef, I'll call
only flush_tlb_kernel_page(), but I'd like to know what is the opinion of the
arch maintainers to do that.
(Who is the maintainer of H8300 arch?)
Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write Protection
On Wed, Jun 17, 2009 at 12:58, Marco wrote: Jared Hulbert wrote: +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300) || \ + ? ? ? defined(CONFIG_BLACKFIN) + ? ? ? /* + ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(), + ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal + ? ? ? ?* to use _range() because many archs just flush the whole TLB. + ? ? ? ?*/ + ? ? ? if (end = start + PAGE_SIZE) + ? ? ? ? ? ? ? flush_tlb_kernel_page(start); + ? ? ? else +#endif + ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end); +} Why not just fix flush_tlb_range()? If an arch has a flush_tlb_kernel_page() that works then it stands to reason that the flush_tlb_kernel_range() shouldn't work with minimal effort, no? flush_tlb_kernel_page() is a new one to me, it doesn't have any mention in Documentation/cachetlb.txt anyways. Many of the flush_tlb_kernel_range() implementations do ranged checks with tunables to determine whether it is more expensive to selectively flush vs just blowing the entire TLB away. Likewise, there is no reason why those 4 architectures can not just shove that if (end = start + PAGE_SIZE) check in the beginning of their flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for those cases. Hiding this in generic code is definitely not the way to go. Ok I'll change that function at arch level and I'll remove the ifdef, I'll call only flush_tlb_kernel_page(), but I'd like to know what is the opinion of the arch maintainers to do that. considering Blackfin defines flush_tlb_kernel_page() to BUG(), i dont think we care what happens. we dont have a MMU, so all tlb funcs - BUG(). presumably this code shouldnt have been compiled in the first place for us. -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
Ralf Baechle wrote: However, on most systems, even embedded, bringing up memory falls on firmware (sometimes in the form of a boot loader) so Linux rarely sees it. There are embedded systems were the firmware does not provide a usuable memory map or where that is plain broken. Or Linux with some extra init code serves as the firmware. Often there is a single serial EEPROM for the entire system. If there is an atrocity that can save a penny it will be commited at least in the embedded world. Rarely is certainly not never. Quite on the contrary. Also, I think you can remove that can save a penny from your last sentence... -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write Protection
On Wed, Jun 17, 2009 at 06:58:00PM +0200, Marco wrote: Jared Hulbert wrote: Why not just fix flush_tlb_range()? If an arch has a flush_tlb_kernel_page() that works then it stands to reason that the flush_tlb_kernel_range() shouldn't work with minimal effort, no? flush_tlb_kernel_page() is a new one to me, it doesn't have any mention in Documentation/cachetlb.txt anyways. Many of the flush_tlb_kernel_range() implementations do ranged checks with tunables to determine whether it is more expensive to selectively flush vs just blowing the entire TLB away. Likewise, there is no reason why those 4 architectures can not just shove that if (end = start + PAGE_SIZE) check in the beginning of their flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for those cases. Hiding this in generic code is definitely not the way to go. Ok I'll change that function at arch level and I'll remove the ifdef, I'll call only flush_tlb_kernel_page(), but I'd like to know what is the opinion of the arch maintainers to do that. (Who is the maintainer of H8300 arch?) No, you should call flush_tlb_kernel_range() and just fix up the flush_tlb_kernel_range() calls to wrap in to flush_tlb_kernel_page(). As far as the kernel is concerned, flush_tlb_kernel_page() is not a standard interface, as it has no mention in Documentation/cachetlb.txt. flush_tlb_page() and flush_tlb_kernel_range() on the other hand are both standard interfaces. H8300 is a nommu platform, so it has no TLB to flush. Yoshinori Sato is the maintainer. Consult the MAINTAINERS file, that's what it is there for. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 09:42:46AM +0300, Mike Rapoport wrote: James Bottomley wrote: We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. Another issue that affects embedded architectures is drivers initialization order. There are a lot of cases when you need the drivers to be initialized in particular order, and current initcalls scheme does not allow fine grained control for it. Look at the early platform device abstraction, this allows specific fine-grained control over when certain drivers are initialized, well before the driver core is available. On SH this is how we deal with our system timers as clockevents/clocksources while just using regular platform devices, and having no other abstraction. You can read more in Documentation/driver-model/platform.txt. For an example, you can grep for earlytimer in arch/sh as well as in drivers/clocksource. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CDC ACM composite gadget serial not working between Linux and Windows?
On Thu, 18 Jun 2009 12:09:24 +1000 Daniel Ng daniel.ng1...@gmail.com wrote: snipp Please suggest an alternate list if this message is inappropriate for this list. I would guess there is a lot more response to this on the linux-usb mailing list: http://vger.kernel.org/vger-lists.html#linux-usb -- Best regards, Hans-Christian Egtvedt -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
