Re: [PATCH 2/2 v4] net/smsc911x: Add regulator support
On Wednesday 16 November 2011 07:59:41 Robert MARKLUND wrote: > From: Mike Frysinger [mailto:vap...@gentoo.org] > > On Monday 31 October 2011 08:38:39 Robert Marklund wrote: > > > ChangeLog v3->v4: > > > - Remove dual prints and old comment on Mike's request. > > > - Split the request_free fucntion on Mike and Sascha request. > > > > would be nice if the enable/disable were split as well ... > > I interpret this as "nice if", if it's a "must be" then ill change it. i would prefer it were split -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 3/4] mmc: Logging neatening
On Tuesday 15 November 2011 20:48:05 NamJae Jeon wrote: > 2011/11/16 Joe Perches : > >mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci > > interrupt */ > > > > - dev_info(&pdev->dev, "DW MMC controller at irq %d, " > > -"%d bit host data width, " > > -"%u deep fifo\n", > > + dev_info(&pdev->dev, > > + "DW MMC controller at irq %d, %d bit host data width, %u deep > > fifo\n", irq, width, fifo_size); > > I think that tab is needed this "DW MMC controller at irq " ? looks to me like this was the only part you replied to. could you please snip the unrelated context in the future ? no reason to include ~1700 lines of context when you only replying to like ~10 lines. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] regulator: Provide dummy supply support
On Friday 28 October 2011 18:47:57 Sascha Hauer wrote: > On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote: > > On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote: > > > drivers/regulator/Makefile|2 +- > > > drivers/regulator/dummy-supply.c | 88 > > > + > > > > We already have a dummy regulator driver and a fixed voltage regulator > > driver, we shouldn't be adding a third implementation of the same thing. > > Just use the fixed voltage regulator for this. > > I explained in my mail why I think that the current implementation of > the dummy regulator is not suitable for things apart from debugging. your complaints seem to be specific to how the dummy regulator gets hooked in and not in the specific regulator implementation. so it seems like the right thing would be to split the kconfig knobs: config REGULATOR_DUMMY - bool "Provide a dummy regulator if regulator lookups fail" + bool "Provide a dummy regulator" +config REGULATOR_DUMMY_FALLBACK + bool "Fallback to dummy regulator if lookup fails" + depends on REGULATOR_DUMMY (and then obviously update the .c files accordingly) -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2 v4] net/smsc911x: Add regulator support
On Monday 31 October 2011 08:38:39 Robert Marklund wrote: > ChangeLog v3->v4: > - Remove dual prints and old comment on Mike's request. > - Split the request_free fucntion on Mike and Sascha request. would be nice if the enable/disable were split as well ... > iounmap(pdata->ioaddr); > > + (void)smsc911x_enable_disable_resources(pdev, false); i don't think the (void) cast is necessary otherwise looks fine -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
On Fri, Oct 28, 2011 at 22:33, Sascha Hauer wrote: > On Thu, Oct 27, 2011 at 02:48:11PM +0200, Linus Walleij wrote: >> +/* >> + * Request or free resources, currently just regulators. >> + * >> + * The SMSC911x has two power pins: vddvario and vdd33a, in designs where >> + * these are not always-on we need to request regulators to be turned on >> + * before we can try to access the device registers. >> + */ >> +static int smsc911x_request_free_resources(struct platform_device *pdev, >> + bool request) > > I had to look twice at this function name. First I thought "request the > free resources?", which other resources would you request if not the > free ones? I think it would be nicer to have two functions instead. > Just my 2 cents. i'll add my 2 cents and we'll almost have a nickle. maybe i'm dense, but i had to look (more than) twice at both funcs before i could get my head around what was happening. no, it's not complicated, but it is unusual in the kernel world. either that or i haven't read enough kernel code to consider this a common paradigm. hopefully it's the former ;). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: provide dummy supply support
On Fri, Oct 28, 2011 at 23:57, Mark Brown wrote: > On Fri, Oct 28, 2011 at 10:26:57PM +0200, Sascha Hauer wrote: >> The following patch allows it for boards to register a dummy supply for >> devices for which no software controllable regulator is available. The >> current CONFIG_REGULATOR_DUMMY and (unused) regulator_use_dummy_regulator() > > Please don't send cover letters for single patch serieses, if there's > content it should probably be in the changelog... sorry for the additional noise, but +1 -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: Provide dummy supply support
On Sat, Oct 29, 2011 at 00:47, Sascha Hauer wrote: > On Fri, Oct 28, 2011 at 11:59:31PM +0200, Mark Brown wrote: >> On Fri, Oct 28, 2011 at 10:26:58PM +0200, Sascha Hauer wrote: >> >> > drivers/regulator/Makefile | 2 +- >> > drivers/regulator/dummy-supply.c | 88 >> > + >> >> We already have a dummy regulator driver and a fixed voltage regulator >> driver, we shouldn't be adding a third implementation of the same thing. >> Just use the fixed voltage regulator for this. > > I explained in my mail why I think that the current implementation of > the dummy regulator is not suitable for things apart from debugging. > > My main concern with the fixed regulator is that it needs quite much > boilerplate code just to say that we have no regulator at all for a > given device. That could also be handled with a helper function which > registers a fixed regulator and only takes the regulator_consumer_supply > as an argument. Would that be ok for you? i think Mark's point is that we have code in dummy.c already to provide a dummy regulator. so your needs sounds like it could be satisfied with some Kconfig/ifdef massaging and the existing drivers/regulator/dummy.c rather than introducing a completely parallel file that is always enabled ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
On Thu, Oct 27, 2011 at 23:42, Mark Brown wrote: > On Thu, Oct 27, 2011 at 10:59:14PM +0200, Mike Frysinger wrote: >> i saw that !CONFIG_REGULATOR works great. my concern is that these >> boards don't define any regulators for smsc resources, so if >> CONFIG_REGULATOR is enabled to test out unrelated daughter cards, i >> don't want the network driver suddenly failing. Linus' comments >> suggest that this is what would happen unless each board file has its >> smsc platform resources extended. maybe i misunderstood what he was saying ? > > That's the case that's handled by CONFIG_REGULATOR_DUMMY - if the lookup > fails the core will provide a virtual regulator to the consumer. If > you're running a setup like that you probably want to enable dummy > regulators anyway. ok, if people configuring need only select that Kconfig symbol to make it work, i'm fine with things. thanks for the explanation. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
On Thu, Oct 27, 2011 at 17:46, Mark Brown wrote: > On Thu, Oct 27, 2011 at 03:21:47PM +0200, Mike Frysinger wrote: >> my gut reaction: smsc911x is working just fine without regulator >> support for many people, so why do we suddenly need to make it a >> requirement ? this is a fairly small amount of code, so adding a >> smsc911x Kconfig symbol to control the regulator support seems like >> overkill. only other option would be to change the patch to not make >> missing regulators non-fatal. so i'd probably lean towards the latter >> (and it sounds like you changed this with earlier versions). > > The regulator API contains a series of generic facilities for stubbing > itself out when not in use - there's no need for individual drivers to > worry about this stuff, they should just rely on the framework. The > main one at the minute is REGULATOR_DUMMY which does what you suggest > and makes regulator_get() never fail. i saw that !CONFIG_REGULATOR works great. my concern is that these boards don't define any regulators for smsc resources, so if CONFIG_REGULATOR is enabled to test out unrelated daughter cards, i don't want the network driver suddenly failing. Linus' comments suggest that this is what would happen unless each board file has its smsc platform resources extended. maybe i misunderstood what he was saying ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
On Thu, Oct 27, 2011 at 14:48, Linus Walleij wrote:
> Platforms that use regulators and the smsc911x and have no defined
> regulator for the smsc911x and claim complete regulator
> constraints with no dummy regulators will need to provide it, for
> example using a fixed voltage regulator. It appears that this may
> affect (apart from Ux500 Snowball) possibly these archs/machines
> that from some grep:s appear to define both CONFIG_SMSC911X and
> CONFIG_REGULATOR:
>
> - ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines
> - Blackfin
> - Super-H
no Blackfin board in the tree uses regulators by default. we do list
regulator resources with some boards so people can rebuild the
development system to support addon daughter cards.
my gut reaction: smsc911x is working just fine without regulator
support for many people, so why do we suddenly need to make it a
requirement ? this is a fairly small amount of code, so adding a
smsc911x Kconfig symbol to control the regulator support seems like
overkill. only other option would be to change the patch to not make
missing regulators non-fatal. so i'd probably lean towards the latter
(and it sounds like you changed this with earlier versions).
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
>
> +#define SMSC911X_NUM_SUPPLIES 2
this gets used once (to define the array), so i wonder if it shouldn't
just be inlined
> +static int smsc911x_enable_disable_resources(struct platform_device *pdev,
> + bool enable)
> +{
> ...
> + if (enable) {
> + ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
> + pdata->supplies);
> + if (ret)
> + netdev_err(ndev, "failed to enable regulators %d\n",
> + ret);
> ...
> static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
> ...
> + retval = smsc911x_request_free_resources(pdev, true);
> + if (retval) {
> + pr_err("Could request regulators needed aborting\n");
you warn twice here, and the grammar in the later error is broken, and
uses pr_err() instead of netdev_err(). i would simply drop the latter
pr_err().
> +static int smsc911x_request_free_resources(struct platform_device *pdev,
> + bool request)
> +{
> ...
> + if (request) {
> + ret = regulator_bulk_get(&pdev->dev,
> + ARRAY_SIZE(pdata->supplies),
> + pdata->supplies);
> + if (ret)
> + netdev_err(ndev, "couldn't get regulators %d\n",
> + ret);
> static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
> ...
> + retval = smsc911x_enable_disable_resources(pdev, true);
> + if (retval) {
> + pr_err("Could enable regulators needed aborting\n");
same exact issues with the request/free helper
> + retval = smsc911x_request_free_resources(pdev, false);
> + /* ignore not all have regulators */
old comment ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP2: avoid descending into disabled framebuffer dirs
Rather than always add the omap2 dirs to the build list (and thus force everyone to generate a useless built-in.o), bind the dirs to their relevant kconfig symbol. Signed-off-by: Mike Frysinger --- drivers/video/omap2/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile index d853d05..5ddef12 100644 --- a/drivers/video/omap2/Makefile +++ b/drivers/video/omap2/Makefile @@ -1,6 +1,6 @@ obj-$(CONFIG_OMAP2_VRAM) += vram.o obj-$(CONFIG_OMAP2_VRFB) += vrfb.o -obj-y += dss/ -obj-y += omapfb/ +obj-$(CONFIG_OMAP2_DSS) += dss/ +obj-$(CONFIG_FB_OMAP2) += omapfb/ obj-y += displays/ -- 1.7.5.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/14] PM / Blackfin: Use struct syscore_ops instead of sysdevs for PM
On Sun, Apr 17, 2011 at 17:11, Rafael J. Wysocki wrote:
> Convert some Blackfin architecture's code to using struct syscore_ops
> objects for power management instead of sysdev classes and sysdevs.
>
> This simplifies the code and reduces the kernel's memory footprint.
> It also is necessary for removing sysdevs from the kernel entirely in
> the future.
looks straight forward enough ...
Acked-by: Mike Frysinger
> +static struct syscore_ops nmi_syscore_ops = {
> .resume = nmi_wdt_resume,
> .suspend = nmi_wdt_suspend,
> };
a bit sad this couldnt be made const
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
On Wed, Sep 29, 2010 at 12:26, Hema HK wrote: > The resource data is getting automatically populated from a set of data > generated from TI's hardware database for the OMAP platform, > While we could hack in some exceptions to that tool to generate resources > in a specific order, it seems less fragile to use the resource name > instead.That way, no matter what order the resources are generated, the > driver still work. > > Modified the OMAP,Blackfin and Davinci architecture files to add the name of > the IRQs > in the resource structures and musb driver to use the get_irq_byname() api to > get the device and dma irq numbers instead of using the index. > > Signed-off-by: Hema HK > Cc: Felipe Balbi > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: Cousson, Benoit > Cc: Paul Walmsley > Cc: Mike Frysinger if Felipe is ok with this, then i'm ok with this Acked-by: Mike Frysinger -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9 v3] usb: musb: Adding names for IRQs in resource structure
On Tue, Sep 28, 2010 at 17:44, Paul Walmsley wrote: > On Tue, 28 Sep 2010, Mike Frysinger wrote: >> On Tue, Sep 28, 2010 at 17:18, Paul Walmsley wrote: >> > On Tue, 28 Sep 2010, Mike Frysinger wrote: >> >> well, currently, your resource definition must always be in the order >> >> of dev int and then dma int. if it isnt, then i dont think musb is >> >> going to work. >> >> >> >> not sure why you wouldnt simply change your platform resources to >> >> match the what the driver expects ... >> > >> > The resource data is getting automatically populated from a set of data >> > generated from TI's hardware database for the OMAP platform, at least. >> > While we could hack in some exceptions to that tool to generate resources >> > in a specific order, it seems less fragile to use the resource name >> > instead. That way, no matter what order the resources are generated, the >> > driver should still work. >> >> guessing you're not referring to a device tree setup, but something >> even more convoluted ? > > No need to disparage it before you've seen it :-) ah, but that's when i do my best work >> i'd highly suggest that this patch be resent with the info you've just >> provided in its changelog so people can get a better understanding of >> the "why" ... i'm not against the patch, it just seemed to be lacking >> any background info > > Hema, would you care to update the patch changelog accordingly? i'll pre-ack that for the Blackfin changes ... or, if you split those out, i can merge it separately for 2.6.37. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9 v3] usb: musb: Adding names for IRQs in resource structure
On Tue, Sep 28, 2010 at 17:18, Paul Walmsley wrote: > On Tue, 28 Sep 2010, Mike Frysinger wrote: >> well, currently, your resource definition must always be in the order >> of dev int and then dma int. if it isnt, then i dont think musb is >> going to work. >> >> not sure why you wouldnt simply change your platform resources to >> match the what the driver expects ... > > The resource data is getting automatically populated from a set of data > generated from TI's hardware database for the OMAP platform, at least. > While we could hack in some exceptions to that tool to generate resources > in a specific order, it seems less fragile to use the resource name > instead. That way, no matter what order the resources are generated, the > driver should still work. guessing you're not referring to a device tree setup, but something even more convoluted ? i'd highly suggest that this patch be resent with the info you've just provided in its changelog so people can get a better understanding of the "why" ... i'm not against the patch, it just seemed to be lacking any background info -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9 v3] usb: musb: Adding names for IRQs in resource structure
On Thu, Sep 23, 2010 at 02:32, Kalliguddi, Hema wrote: >From: Kalliguddi, Hema >>Modified the Omap,Blackfin and Davinci board files to add the >>name of the IRQs >>in the resource structures and musb driver to use the >>get_irq_byname() api to >>get the mc and dma irq numbers instead of using the index as >>the order of i dont see a problem with the existing code (going by index #), but i dont really care either way >>resource definition need not be always in order of device interrupt and >>then dma interrupt well, currently, your resource definition must always be in the order of dev int and then dma int. if it isnt, then i dont think musb is going to work. not sure why you wouldnt simply change your platform resources to match the what the driver expects ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: musb-gadget: fix bulk IN infinite hangs in double buffer case
On Friday, August 27, 2010 07:37:20 tom.leim...@gmail.com wrote:
> From: Ming Lei
>
> This patch fixes one infinite hang of bulk IN transfer in double buffer
> case, the hang can be observed easily by test #6 of usbtest if musb is
> configured as g_zero and fifo mode 3 is taken to enable double fifo.
>
> In fact, the patch only removes the check for non-empty fifo before
> loading data from new request into fifo since the check is not correct:
>
> -in double buffer case, fifo may accommodate more than one packet,
> even though it has contained one packet already and is non-empty
>
> -since last DMA is completed before calling musb_g_tx, it is sure
> that fifo may accommodate at least one packet
>
> Without applying the patch, new requst enqueued from .complte may not
> have a chance to be loaded into fifo, then will never be completed and
> cause infinite hangs.
>
> With the patch, on my beagle B5, test#6(queued bulk in) can be passed and
> test result may go beyond 33Mbyte/s if musb is configured as g_zero and
> fifo mode 3 is taken, follows the test command:
>
> #testusb -D DEV_NAME -c 1024 -t 6 -s 32768 -g 8 [1]
>
> [1],
> -source of testusb : tools/usb/testusb.c under linux kernel;
>
> Signed-off-by: Ming Lei
> Cc: Anand Gadiyar
> Cc: Mike Frysinger
> Cc: Sergei Shtylyov
>
> ---
> drivers/usb/musb/musb_gadget.c | 12
> 1 files changed, 0 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_gadget.c
> b/drivers/usb/musb/musb_gadget.c index 550b397..e0bd1c1 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -506,18 +506,6 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> /* ... or if not, then complete it. */
> musb_g_giveback(musb_ep, request, 0);
>
> - /*
> - * Kickstart next transfer if appropriate;
> - * the packet that just completed might not
> - * be transmitted for hours or days.
> - * REVISIT for double buffering...
> - * FIXME revisit for stalls too...
> - */
> - musb_ep_select(mbase, epnum);
> - csr = musb_readw(epio, MUSB_TXCSR);
> - if (csr & MUSB_TXCSR_FIFONOTEMPTY)
> - return;
> -
> request = musb_ep->desc ? next_request(musb_ep) : NULL;
> if (!request) {
> DBG(4, "%s idle now\n",
maybe this change will make a difference ?
From 13fa6c9cec387893e2b22db6c055028f96fea5b8 Mon Sep 17 00:00:00 2001
From: Cliff Cai
Date: Fri, 3 Jul 2009 06:32:02 +
Subject: [PATCH] USB: musb: only complete the request when all data has been
transfered [local/log]
bug[#5269],bug[#5268],bug[#5264]only complete the request when all data has
been transfered
git-svn-id: svn://localhost/svn/linux-kernel/tr...@6915 526b6c2d-f592-4532-
a319-5dd88ccb003d
---
drivers/usb/musb/musb_gadget.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6fca870..f019843 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -500,6 +500,8 @@ void musb_g_tx(struct musb *musb, u8 epnum)
| MUSB_TXCSR_TXPKTRDY);
request->zero = 0;
}
+ if (request->actual < request->length)
+ return;
/* ... or if not, then complete it. */
musb_g_giveback(musb_ep, request, 0);
--
1.7.2.2
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] touchscreen: ads7846: please don't touch free'd memory
On Tue, May 25, 2010 at 17:46, Kevin Hilman wrote: > After digging into the driver core and realizing that it seemed to > have sane error handling itself, I took a closer look at > ads7846_probe() and discovered it doesn't actually return an error > code for certain failure cases! That was the root cause. that is crappy > Subject: [PATCH] input: touchscreen: ads7846: return error on probe failure i'd refer to the specific probe issue rather than just "probe". maybe: input: touchscreen: ads7846: return error on regulator_get() failure otherwise: Acked-by: Mike Frysinger -mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] backlight: mark struct backlight_ops const
On Sat, Feb 20, 2010 at 18:18, Bruno Prémont wrote: > drivers/video/bf54x-lq043fb.c | 2 +- > drivers/video/bfin-t350mcqb-fb.c | 2 +- Acked-by: Mike Frysinger -mike
Re: [RFC] [PATCH] watchdog_info separation and constify
On Tue, Jan 19, 2010 at 16:42, Joe Perches wrote:
> On Tue, 2010-01-19 at 22:17 +0100, Wim Van Sebroeck wrote:
>> -static struct watchdog_info at32_wdt_info = {
>> +static const struct watchdog_info at32_wdt_info = {
>
> It'd be good to use a consistent structure name:
>
> static const struct watchdog_info ident = {
> etc...
> }
i'd agree (obviously i'm partial to the "xxx_wdt_info" form), but i'd
worry about this after the watchdog implementations are finally
unified ... might be less code needing standardization at that point
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] MUSB: 2 patches to fix some bug found on Blackfin
On Wed, May 21, 2008 at 4:04 PM, David Brownell wrote: > That said, I'm looking forward to seeing the www.beagleboard.org > hardware [1] become more generally available. That will make some > musb_hdrc hardware available in a more developer-friendly rig than, > say, an N810 tablet. And it might well get more folk in a position > where they can use that driver! (I think some Blackfin devboards > are available already, but they're more pricey.) unfortunately, that is the case. the BF527 EZKit is ~$900 while the BF548 EZKit is ~$1000. i'm hoping us software guys keep complaining enough for the hardware guys to put out a bare bone kit at a reasonable price (sub $300). -mike -- 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: [PATCH 2/2] MUSB: Real fix bug 4 usb bugs found on Blackfin
On Mon, May 19, 2008 at 11:16 AM, Gadiyar, Anand <[EMAIL PROTECTED]> wrote: > I am unable to visit any of these links. I get the following error "Unknown > or invalid plugin: 'tracker'". change "linux-kernel" in the url to "uclinux-dist" -mike -- 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
