[PATCH] PM related changes:McSPI
PM related changes for McSPI
Signed-off-by: Girish S G <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/devices.c | 26 -
drivers/spi/omap2_mcspi.c | 195 ++
2 files changed, 204 insertions(+), 17 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2008-07-30
16:49:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c2008-07-30
16:57:53.0
+0530
@@ -168,6 +168,11 @@
.end= OMAP2_MCSPI1_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_24XX_SPI1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi1 = {
@@ -190,6 +195,11 @@
.end= OMAP2_MCSPI2_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_24XX_SPI2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi2 = {
@@ -209,9 +219,14 @@
static struct resource omap2_mcspi3_resources[] = {
{
- .start = OMAP2_MCSPI3_BASE,
- .end= OMAP2_MCSPI3_BASE + 0xff,
- .flags = IORESOURCE_MEM,
+ .start = OMAP2_MCSPI3_BASE,
+ .end= OMAP2_MCSPI3_BASE + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+
+ {
+ .start = INT_24XX_SPI3_IRQ,
+ .flags = IORESOURCE_IRQ,
},
};
@@ -237,6 +252,11 @@
.end= OMAP2_MCSPI4_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_34XX_SPI4_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi4 = {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2008-07-30
16:49:59.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2008-07-30 17:11:23.0
+0530
@@ -35,6 +35,8 @@
#include
+#include
+#include
#include
#include
@@ -61,8 +63,11 @@
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 << 0)
#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET(1 << 1)
+#define OMAP2_AFTR_RST_SET_MASTER (0 << 2)
#define OMAP2_MCSPI_SYSSTATUS_RESETDONE(1 << 0)
+#define OMAP2_MCSPI_SYS_CON_LVL_1 1
+#define OMAP2_MCSPI_SYS_CON_LVL_2 2
#define OMAP2_MCSPI_MODULCTRL_SINGLE (1 << 0)
#define OMAP2_MCSPI_MODULCTRL_MS (1 << 2)
@@ -84,6 +89,11 @@
#define OMAP2_MCSPI_CHCONF_TURBO (1 << 19)
#define OMAP2_MCSPI_CHCONF_FORCE (1 << 20)
+#define OMAP2_MCSPI_SYSCFG_WKUP(1 << 2)
+#define OMAP2_MCSPI_SYSCFG_IDL (2 << 3)
+#define OMAP2_MCSPI_SYSCFG_CLK (2 << 8)
+#define OMAP2_MCSPI_WAKEUP_EN (1 << 1)
+#define OMAP2_MCSPI_IRQ_WKS(1 << 16)
#define OMAP2_MCSPI_CHSTAT_RXS (1 << 0)
#define OMAP2_MCSPI_CHSTAT_TXS (1 << 1)
#define OMAP2_MCSPI_CHSTAT_EOT (1 << 2)
@@ -128,6 +138,15 @@
int word_len;
};
+#if defined(CONFIG_OMAP34XX_OFFMODE) && defined(CONFIG_OMAP3_PM)
+struct omap_mcspi_regs {
+ u32 sysconfig;
+ u32 modulctrl;
+ u32 chconf0;
+ u32 chconf1;
+};
+static struct omap_mcspi_regs mcspi_ctx[4];
+#endif /* #ifdef CONFIG_OMAP34XX_OFFMODE */
static struct workqueue_struct *omap2_mcspi_wq;
#define MOD_REG_BIT(val, mask, set) do { \
@@ -152,6 +171,14 @@
return __raw_readl(mcspi->base + idx);
}
+static inline void mcspi_write_wkup_reg(struct spi_master *master,
+ int idx, u32 val)
+{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+ __raw_writel(val, mcspi->base + idx);
+}
+
static inline void mcspi_write_cs_reg(const struct spi_device *spi,
int idx, u32 val)
{
@@ -214,6 +241,99 @@
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
}
+static void omap_mcspi_wakeup_enable(struct spi_master *spi_cntrl, int level)
+{
+ if (level == OMAP2_MCSPI_SYS_CON_LVL_1)
+ mcspi_write_wkup_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ (mcspi_read_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG) |
+OMAP2_MCSPI_SYSCFG_WKUP | OMAP2_MCSPI_SYSCFG_IDL |
+OMAP2_MCSPI_SYSCFG_CLK |
+ OMAP2_MCSPI_SYSCONFIG_AUTOIDLE));
+
+ if (level == OMAP2_MCSPI_SYS_CON_LVL_2)
+ mcspi_write_wkup_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ (mcspi_read_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG) |
+ OMAP2_MCSPI_SYSCFG
Re: USB driver issue
Hi, On Wed, Jul 30, 2008 at 2:59 PM, SUBHRANIL CHOUDHURY <[EMAIL PROTECTED]> wrote: > Hi all, > I am trying to validate the USB driver on OMAP3430 with the > 2.6.22.18kernel. I am facing problems in the process while trying to > do a USB > transfer with DMA enabled. > The apllication is breaking in a function called consistent_sync. The error > message is like "Unable to handle kernel Null pointer". > > The issue is same with both OHCI and EHCI controller. And the issue is not > coming if i disable DMA. > > Has anyone tried USB packet transfer with DMA enabled? Please let me know. Why are you using such an old, support-less kernel ? Try with current 2.6.26 out of git repository. I've been using musb driver on omap3 for months now and it's working quite ok besides a few bugs hidden here and there (which I'm looking at). ps: this list has moved to linux-omap@vger.kernel.org and musb driver is now being discussed in [EMAIL PROTECTED] mailing list, so please, care to Cc both lists mentioned here. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
What is the application you are using and could you turn the musb driver debug options? You can try it by echo "D 3" > /proc/driver/musb_hdrc (Check if MUSB_DEBUG is enabled). This should give more helpful messages. >-Original Message- >From: [EMAIL PROTECTED] [mailto:linux-omap-open- >[EMAIL PROTECTED] On Behalf Of SUBHRANIL CHOUDHURY >Sent: Wednesday, July 30, 2008 5:50 PM >To: Gadiyar, Anand >Cc: [EMAIL PROTECTED] >Subject: Re: USB driver issue > >hi, >I am using Mistral OMAP3430 OSK2.1 board. It is the USB OTG port. >The Philips tranciever ISP1504. >I am enabling the EHCI and OHCI in the kernel menuconfig. > >This was the error print i was getting: > >Unable to handle kernel NULL pointer dereference at virtual address >pgd = c54d8000 >[] *pgd=81401031, *pte=, *ppte= >Internal error: Oops: 817 [#1] >Modules linked in: >CPU: 0Not tainted (2.6.22.18-omap3 #29) >PC is at consistent_sync+0x40/0xa4 >LR is at usb_hcd_submit_urb+0x7b0/0x8b4 >pc : []lr : []psr: 2013 >sp : c1403c48 ip : c1403c58 fp : c1403c54 >r10: 8003 r9 : 0020 r8 : 0020 >r7 : c483dc20 r6 : c0569000 r5 : c23c040c r4 : ff2d2000 >r3 : r2 : 0002 r1 : ff2dba38 r0 : ff2d2000 >Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user >Control: 00c5387f Table: 854d8018 DAC: 0015 > >Do you get some clue from this about what is happening? > > > > >On Wed, Jul 30, 2008 at 5:35 PM, Gadiyar, Anand <[EMAIL PROTECTED]> wrote: > >> > Hi all, >> > I am trying to validate the USB driver on OMAP3430 with the >> > 2.6.22.18kernel. I am facing problems in the process while trying to >> > do a USB transfer with DMA enabled. >> > The apllication is breaking in a function called >> > consistent_sync. The error message is like "Unable to handle kernel Null >> pointer". >> >> Which board are you using? Which is the USB port - EHCI/OHCI/OTG? >> >> Assuming it is the USB OTG port (because that is the only one where you >> can enable or disable DMA), what is the transceiver being used on the port? >> >> >> > The issue is same with both OHCI and EHCI controller. And the >> > issue is not coming if i disable DMA. >> >> I don't think you have control over DMA disabling with the OHCI/EHCI >> controller. Are you sure you are using the OHCI/EHCI controller? >> >> The "Unable to handle kernel Null pointer" message comes with some more >> data. >> We won't be able to help you out without the rest of the log, but the >> answers to >> questions above are essential before we move on to this. >> >> > >> > Has anyone tried USB packet transfer with DMA enabled? Please >> > let me know. >> > >> > Regards, >> > Subhro >> >___ >Linux-omap-open-source mailing list >[EMAIL PROTECTED] >http://linux.omap.com/mailman/listinfo/linux-omap-open-source -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 06:28:35PM +0530, ext Dasgupta, Romit wrote: > What is the application you are using and could you turn the musb driver > debug options? You can try it by > > echo "D 3" > /proc/driver/musb_hdrc (Check if MUSB_DEBUG is enabled). it's D3, together :-) > > This should give more helpful messages. > > > > >-Original Message- > >From: [EMAIL PROTECTED] [mailto:linux-omap-open- > >[EMAIL PROTECTED] On Behalf Of SUBHRANIL CHOUDHURY > >Sent: Wednesday, July 30, 2008 5:50 PM > >To: Gadiyar, Anand > >Cc: [EMAIL PROTECTED] > >Subject: Re: USB driver issue > > > >hi, > >I am using Mistral OMAP3430 OSK2.1 board. It is the USB OTG port. > >The Philips tranciever ISP1504. > >I am enabling the EHCI and OHCI in the kernel menuconfig. > > > >This was the error print i was getting: > > > >Unable to handle kernel NULL pointer dereference at virtual address > >pgd = c54d8000 > >[] *pgd=81401031, *pte=, *ppte= > >Internal error: Oops: 817 [#1] > >Modules linked in: > >CPU: 0Not tainted (2.6.22.18-omap3 #29) > >PC is at consistent_sync+0x40/0xa4 > >LR is at usb_hcd_submit_urb+0x7b0/0x8b4 > >pc : []lr : []psr: 2013 > >sp : c1403c48 ip : c1403c58 fp : c1403c54 > >r10: 8003 r9 : 0020 r8 : 0020 > >r7 : c483dc20 r6 : c0569000 r5 : c23c040c r4 : ff2d2000 > >r3 : r2 : 0002 r1 : ff2dba38 r0 : ff2d2000 > >Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user > >Control: 00c5387f Table: 854d8018 DAC: 0015 > > > >Do you get some clue from this about what is happening? there must be a backtrace right after that, can you paste it as well? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X series a kernel 2.6.22 can not be labeled as old. Besides it comes along with few distros as default kernel. A lot of people like me need some kind of a stable version that we can relay on for more than playing at home, which is the case with 2.4.X tree. Personally, experiments with 2.6.24 brought me into a big trouble and it took many hours to migrate back to 2.6.20, so please keep in mind that if we say something like this, there is a good reason to do so. Appreciate your understanding. --- On Wed, 7/30/08, Felipe Balbi <[EMAIL PROTECTED]> wrote: > From: Felipe Balbi <[EMAIL PROTECTED]> > Subject: Re: USB driver issue > To: "SUBHRANIL CHOUDHURY" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], linux-omap@vger.kernel.org, [EMAIL PROTECTED] > Date: Wednesday, July 30, 2008, 2:05 PM > Hi, > > On Wed, Jul 30, 2008 at 2:59 PM, SUBHRANIL CHOUDHURY > <[EMAIL PROTECTED]> wrote: > > Hi all, > > I am trying to validate the USB driver on OMAP3430 > with the > > 2.6.22.18kernel. I am facing problems in the process > while trying to > > do a USB > > transfer with DMA enabled. > > The apllication is breaking in a function called > consistent_sync. The error > > message is like "Unable to handle kernel Null > pointer". > > > > The issue is same with both OHCI and EHCI controller. > And the issue is not > > coming if i disable DMA. > > > > Has anyone tried USB packet transfer with DMA enabled? > Please let me know. > > Why are you using such an old, support-less kernel ? > > Try with current 2.6.26 out of git repository. I've > been using musb > driver on omap3 > for months now and it's working quite ok besides a few > bugs hidden > here and there > (which I'm looking at). > > ps: this list has moved to linux-omap@vger.kernel.org and > musb driver > is now being > discussed in [EMAIL PROTECTED] mailing list, so > please, care > to Cc both lists > mentioned here. > > -- > Best Regards, > > Felipe Balbi > [EMAIL PROTECTED] > -- > To unsubscribe from this list: send the line > "unsubscribe linux-usb" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote: > Dear Felipe, I just want to tell, that while still developing kernels in the > 2.6.2X series a kernel 2.6.22 can not be labeled as old. Actually, it can, as it was released quite a long time ago. > Besides it comes along with few distros as default kernel. Yes, and these distros have to heavily patch it. > A lot of people like me need some kind of a stable version that we can relay > on for more than playing at home, which is the case with 2.4.X tree. > > Personally, experiments with 2.6.24 brought me into a big trouble and it took > many hours to migrate back to 2.6.20, so please keep in mind that if we say > something like this, there is a good reason to do so. I'd strongly suggest trying 2.6.26. Cheers, Daniel signature.asc Description: Digital signature
Re: USB driver issue
On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote: > > Dear Felipe, I just want to tell, that while still developing kernels in the > 2.6.2X series a kernel 2.6.22 can not be labeled as old. Besides it comes > along with few distros as default kernel. > > A lot of people like me need some kind of a stable version that we can relay > on for more than playing at home, which is the case with 2.4.X tree. > > Personally, experiments with 2.6.24 brought me into a big trouble and it took > many hours to migrate back to 2.6.20, so please keep in mind that if we say > something like this, there is a good reason to do so. You can always choose any kernel version you want but if you choose such an old version (2.6.22 was released in Jul 8th, 2007), please don't rely in community support and instead, backport all changes in the particular driver you're working with to 2.6.22. It's always your choice. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
> On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote: > > > > Dear Felipe, I just want to tell, that while still developing kernels in > > the 2.6.2X > series a kernel 2.6.22 can not be labeled as old. Besides it comes along with > few > distros as default kernel. > > > > A lot of people like me need some kind of a stable version that we can > > relay on > > for more than playing at home, which is the case with 2.4.X tree. > > > > Personally, experiments with 2.6.24 brought me into a big trouble and it > > took > > many hours to migrate back to 2.6.20, so please keep in mind that if we say > > something like this, there is a good reason to do so. > > You can always choose any kernel version you want but if you choose such > an old version (2.6.22 was released in Jul 8th, 2007), please don't rely > in community support and instead, backport all changes in the particular > driver you're working with to 2.6.22. > > It's always your choice. That's plain wrong. 2.6.22 was released in July 2007. But 2.6.22.18 was not. That came much later - in February this year. And people still do use 2.6.22 kernels. Besides, the MUSB code hasn't really changed that much in this time. Do you really think the problem will go away in 2.6.26? People can't always use the latest kernel, you know. Embedded kernels don't get enough testing. There's always a chance this is a new driver. And even if it weren't, the very act of debugging a problem like this is a good learning experience. Grr. Saying one needs to upgrade to the latest kernel before one can expect support is a bit like certain proprietary OS vendors - and even they do a better job than this. Regards, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
>> On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote: >> > >> > Dear Felipe, I just want to tell, that while still developing kernels in >> > the 2.6.2X >> series a kernel 2.6.22 can not be labeled as old. Besides it comes along >> with few >> distros as default kernel. >> > >> > A lot of people like me need some kind of a stable version that we can >> > relay on >>> > for more than playing at home, which is the case with 2.4.X tree. >> > >> > Personally, experiments with 2.6.24 brought me into a big trouble and it >> > took >> > many hours to migrate back to 2.6.20, so please keep in mind that if we say >> > something like this, there is a good reason to do so. >> >> You can always choose any kernel version you want but if you choose such >> an old version (2.6.22 was released in Jul 8th, 2007), please don't rely >> in community support and instead, backport all changes in the particular >> driver you're working with to 2.6.22. >> >> It's always your choice. > > That's plain wrong. 2.6.22 was released in July 2007. But 2.6.22.18 was not. > That came much later - in February this year. And people still do use 2.6.22 > kernels. Besides, the MUSB code hasn't really changed that much in this time. > > Do you really think the problem will go away in 2.6.26? People can't always > use the > latest kernel, you know. Embedded kernels don't get enough testing. There's > always > a chance this is a new driver. And even if it weren't, the very act of > debugging > a problem like this is a good learning experience. I meant new bug. > > Grr. Saying one needs to upgrade to the latest kernel before one can expect > support is a bit like certain proprietary OS vendors - and even they do a > better > job than this. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 09:53:43PM +0530, ext Gadiyar, Anand wrote: > Grr. Saying one needs to upgrade to the latest kernel before one can expect > support is a bit like certain proprietary OS vendors - and even they do a > better > job than this. If you want to support people running 2.6.22, good for you. You seem to be happy with a codebase that doesn't change as much, so I'm sure you'll have fun supporting it. I'm getting the feeling that we need a new Godwin's law: as a thread involving a complaint about open source grows longer, the probability of a comparison involving Microsoft approaches one. So yes, some people don't want to support old code on their own time. So what? Who are you to tell them that they can't do this? What was the point of the Microsoft comparison, except to reinforce stereotypes that free software developers are a bunch of freaks with unhealthy obsessions on Microsoft and LOL BILL GATES IS THE SUCK? (Bearing in mind that one of the main tenets of open source development is 'release early and release often', you could say that having everyone use very old code until you one day drop a huge chunk of rewritten new code on them is also OMG MICROSOFT. But that'd be equally stupid.) signature.asc Description: Digital signature
Re: USB driver issue
On Wed, Jul 30, 2008 at 09:56:48PM +0530, Gadiyar, Anand wrote: > > That's plain wrong. 2.6.22 was released in July 2007. But 2.6.22.18 was not. > > That came much later - in February this year. And people still do use 2.6.22 > > kernels. Besides, the MUSB code hasn't really changed that much in this > > time. > > > > Do you really think the problem will go away in 2.6.26? People can't always > > use the > > latest kernel, you know. Embedded kernels don't get enough testing. There's > > always > > a chance this is a new driver. And even if it weren't, the very act of > > debugging > > a problem like this is a good learning experience. > > I meant new bug. > > > > > Grr. Saying one needs to upgrade to the latest kernel before one can expect > > support is a bit like certain proprietary OS vendors - and even they do a > > better > > job than this. It can also be a fixed bug and there's no reason to try to fix it "again". The time frame from 2.6.22-omap1 (linux-omap tag) until now contains the most active development on musb driver. Several hw workarounds were found, omap3 support was added, several cleanups were done and a lot more. It's a +16k lines diff. I'd rather try it in a recent kernel just to be sure the bug still in, if it's not we try to find where is the fix and backport it to 2.6.22 kernel. For me it sounds mych saner going this way. I really don't see how this relates to proprietary OS vendors support. I'm pretty sure kernel from omapzoom would have support for his 3430 osk board, wouldn't it? Besides, wouldn't that board work with board-omap3evm.c code just by tweaking the machine type ? I really believe it'd be something good to try, either recent linux-omap or omapzoom git tree. I believe still 2.6.24 right ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
On Wed, 2008-07-30 at 21:56 +0530, ext Gadiyar, Anand wrote: > > Grr. Saying one needs to upgrade to the latest kernel before one can expect > > support is a bit like certain proprietary OS vendors - and even they do a > > better > > job than this. The difference is that an OS vendor usually sells also support. Even if it was confirmed that the bug exists in a "stable" version, the reporter would be asked anyway to verify that it is present in the latest code. Of course for TI the business is different, since TI does provide also support to customers, but that doesn't imply that others have to follow that model. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
> On Wed, Jul 30, 2008 at 09:53:43PM +0530, ext Gadiyar, Anand wrote: > > Grr. Saying one needs to upgrade to the latest kernel before one can expect > > support is a bit like certain proprietary OS vendors - and even they do a > > better > > job than this. > > If you want to support people running 2.6.22, good for you. You seem to > be happy with a codebase that doesn't change as much, so I'm sure you'll > have fun supporting it. Second sentence isn't true. The third probably is. I do enjoy finding why something doesn't work. Maybe you should give it a shot sometime. > I'm getting the feeling that we need a new Godwin's law: as a thread > involving a complaint about open source grows longer, the probability of > a comparison involving Microsoft approaches one. Okay. That comparison wasn't warranted, I guess. But here's what went through my mind when I read Felipe's post. "If you want this to work, then upgrade". And that looked exactly like MS telling me "I can't help you with XP anymore, move on to Vista mate". Why on earth do we have the stable trees then? Why do people put in their time porting fixes back to the 2.6.22.* 'stable' trees? There are still people out there that use them, for whatever reason. And they do run into bugs that still haven't been caught. > So yes, some people don't want to support old code on their own time. > So what? Who are you to tell them that they can't do this? What was the I don't particularly care if people don't want to support old code. What I do care about is the attitude that's out here - "Hey! Move up in life man! Get the latest, greatest, RC kernel! 2.6.24 is ancient, 2.6.26 is ancient!". Yes, I do use 2.6.27-rc1 prepatch. But I do recognize that there are people out there who don't. Yes people should ideally work off the latest. But that shouldn't mean one won't get help if one is not using the latest. Or am I totally wrong here? > point of the Microsoft comparison, except to reinforce stereotypes that > free software developers are a bunch of freaks with unhealthy obsessions > on Microsoft and LOL BILL GATES IS THE SUCK? The Microsoft comparison was totally out of place. Please accept my apologies for bringing it up. > > (Bearing in mind that one of the main tenets of open source development > is 'release early and release often', you could say that having > everyone use very old code until you one day drop a huge chunk of > rewritten new code on them is also OMG MICROSOFT. But that'd be > equally stupid.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
> On Wed, 2008-07-30 at 21:56 +0530, ext Gadiyar, Anand wrote: > > > > Grr. Saying one needs to upgrade to the latest kernel before one can > > > expect > > > support is a bit like certain proprietary OS vendors - and even they do a > > > better > > > job than this. > > The difference is that an OS vendor usually sells also support. > > Even if it was confirmed that the bug exists in a "stable" version, the > reporter would be asked anyway to verify that it is present in the > latest code. Yes. Except that the poor old OP would have a hard time getting the latest kernel to run on his hardware... :) (Actually, he shouldn't have much of a problem. So your point is taken). It would be nice if everyone were to migrate to the latest code, but does that really take away the fun of solving a problem? I agree we shouldn't try to fix something that, in all likelyhood, has already been fixed. But is it really so much of an effort for us to trace a problem without making the OP figure out how to get a totally new kernel running? Are we really this lazy? > Of course for TI the business is different, since TI does provide also > support to customers, but that doesn't imply that others have to follow > that model. Oh well! Just because one has a corporate email account... :) I guess it's time I started using a non-corporate account for work done in my spare time. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 10:55:03PM +0530, Gadiyar, Anand wrote: > Okay. That comparison wasn't warranted, I guess. But here's what went through > my mind when I read Felipe's post. "If you want this to work, then upgrade". > And > that looked exactly like MS telling me "I can't help you with XP anymore, > move on > to Vista mate". eheh, did I really say that ? I hope not. :-p What I meant is that it's possible that recent code has that particular bug fixed. > Why on earth do we have the stable trees then? Why do people put in their time > porting fixes back to the 2.6.22.* 'stable' trees? There are still people out > there > that use them, for whatever reason. And they do run into bugs that still > haven't been > caught. But then again, if the problem _is_ solved in current tree then it's easier to just backport then trying to solve it again. If it _does_ exist in current code, then we fix both in a shot. > I don't particularly care if people don't want to support old code. What I do > care about is the attitude that's out here - "Hey! Move up in life man! Get > the > latest, greatest, RC kernel! 2.6.24 is ancient, 2.6.26 is ancient!". Yes, I > do use > 2.6.27-rc1 prepatch. But I do recognize that there are people out there who > don't. We do recognize as well. We're still releasing maemo sw with 2.6.21 kernel. > Yes people should ideally work off the latest. But that shouldn't mean one > won't > get help if one is not using the latest. Or am I totally wrong here? Again, if there is more recent code to try out, I really don't see why not trying out that more recent code to see if the same bug shows up. It'll make things easier to track down. We should know if we were able to fix it since 2.6.22 until today, then we just track the changes in that particular function and it's a lot easier to backport the fix, don't you think ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 11:02:27PM +0530, Gadiyar, Anand wrote: > It would be nice if everyone were to migrate to the latest code, but does that > really take away the fun of solving a problem? I agree we shouldn't try to > fix something > that, in all likelyhood, has already been fixed. But is it really so much of > an effort for us > to trace a problem without making the OP figure out how to get a totally new > kernel > running? Are we really this lazy? I wouldn't say lazy. At least I have several other stuff internally to deal with and if this is an already fixed bug, I really wouldn't like to spend time fixing it again. Maybe this discussion is already too big and we're not trying to solve the problem anyways. So here are a few questions: 1. Can linux-omap boot up omap3 osk ? 2. Can omapzoom kernel boot up omap3 osk ? 3. Can you try to see if the bug appears in both of those kernels ? 4. Can you send more detailed debugging messages ? 5. Can you describe a way to reproduce the bug ? Please, keep my nokia mail in the loop so I can take a look at it after we get more information :-) -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 09:53:43PM +0530, Gadiyar, Anand wrote: > Besides, the MUSB code hasn't really changed that much in this time. Even if that was true (which, according to Felippe's answer isn't), the USB subsystem itself has changed quite a bit since. > Do you really think the problem will go away in 2.6.26? People can't always > use the > latest kernel, you know. Embedded kernels don't get enough testing. Certainly the best way to fix that is to ask embedded people to test newer kernels then? If for no other reason, to find out _why_ people can't use newer kernels - If it's some valid brokenness is mainline kernels, those bugs need to be found and fixed, rather than having developers sulking with their old kernels... > Grr. Saying one needs to upgrade to the latest kernel before one can expect > support is a bit like certain proprietary OS vendors - and even they do a > better > job than this. There is fine line between "you must use latest kernel" and "please do me a favour and test with this latest version that already might have the fix". Vendors and Distributions provide stable baseline Linux kernels - but then you should get support from the vendor rather than from community in general. Now this mailing list is probable the right contact place for TI provided kernels so this point is a bit moot ;) -- "rm -rf" only sounds scary if you don't have backups -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
