* [PATCH v4 00/22] Updates for Tegra support in 2.6.39
From: Colin Cross @ 2011-02-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297320204-31882-1-git-send-email-ccross@android.com>
On Wed, Feb 9, 2011 at 10:43 PM, Colin Cross <ccross@android.com> wrote:
> This is a repost of the same series with the suspend and
> idle support dropped for now while the necessary changes
> to the gic, l2x0, and init notifiers are discussed. ?If
> there are no further comments, I will push these to
> tegra/for-next.
>
> ?arch/arm/configs/tegra_defconfig ? ? ? ? ? ? ? | ?123 +++++++++++
> ?arch/arm/mach-tegra/Makefile ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-tegra/board.h ? ? ? ? ? ? ? ? ? ?| ? ?2 +
> ?arch/arm/mach-tegra/common.c ? ? ? ? ? ? ? ? ? | ? 17 ++-
> ?arch/arm/mach-tegra/cpu-tegra.c ? ? ? ? ? ? ? ?| ? 75 ++++++--
> ?arch/arm/mach-tegra/dma.c ? ? ? ? ? ? ? ? ? ? ?| ?198 ++++++++++--------
> ?arch/arm/mach-tegra/gpio.c ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-tegra/include/mach/debug-macro.S | ? 25 +--
> ?arch/arm/mach-tegra/include/mach/iomap.h ? ? ? | ? 69 +++++-
> ?arch/arm/mach-tegra/include/mach/irqs.h ? ? ? ?| ? 14 +-
> ?arch/arm/mach-tegra/include/mach/legacy_irq.h ?| ? ?4 +
> ?arch/arm/mach-tegra/include/mach/pinmux-t2.h ? | ? 10 +
> ?arch/arm/mach-tegra/include/mach/powergate.h ? | ? 40 ++++
> ?arch/arm/mach-tegra/include/mach/suspend.h ? ? | ? 38 ++++
> ?arch/arm/mach-tegra/include/mach/system.h ? ? ?| ? 10 +-
> ?arch/arm/mach-tegra/include/mach/uncompress.h ?| ? 18 +--
> ?arch/arm/mach-tegra/irq.c ? ? ? ? ? ? ? ? ? ? ?| ?186 ++++++++---------
> ?arch/arm/mach-tegra/legacy_irq.c ? ? ? ? ? ? ? | ?109 ++++++++++-
> ?arch/arm/mach-tegra/pinmux-t2-tables.c ? ? ? ? | ? 26 ++-
> ?arch/arm/mach-tegra/powergate.c ? ? ? ? ? ? ? ?| ?212 +++++++++++++++++++
> ?arch/arm/mach-tegra/tegra2_clocks.c ? ? ? ? ? ?| ?264 ++++++++++++++++++++++--
> ?arch/arm/mach-tegra/timer.c ? ? ? ? ? ? ? ? ? ?| ? 61 ++++++-
> ?22 files changed, 1212 insertions(+), 291 deletions(-)
>
I pushed this patch set to tegra/for-next, with minor fixups from
Stephen Warren.
^ permalink raw reply
* Re: [PATCH v4 00/22] Updates for Tegra support in 2.6.39
From: Colin Cross @ 2011-02-12 8:52 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
olof-nZhT3qVonbNeoWH0uzbU5w, konkers-z5hGa2qSFaRBDgjK7y7TUQ,
Colin Cross
In-Reply-To: <1297320204-31882-1-git-send-email-ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>
On Wed, Feb 9, 2011 at 10:43 PM, Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org> wrote:
> This is a repost of the same series with the suspend and
> idle support dropped for now while the necessary changes
> to the gic, l2x0, and init notifiers are discussed. If
> there are no further comments, I will push these to
> tegra/for-next.
>
> arch/arm/configs/tegra_defconfig | 123 +++++++++++
> arch/arm/mach-tegra/Makefile | 1 +
> arch/arm/mach-tegra/board.h | 2 +
> arch/arm/mach-tegra/common.c | 17 ++-
> arch/arm/mach-tegra/cpu-tegra.c | 75 ++++++--
> arch/arm/mach-tegra/dma.c | 198 ++++++++++--------
> arch/arm/mach-tegra/gpio.c | 1 +
> arch/arm/mach-tegra/include/mach/debug-macro.S | 25 +--
> arch/arm/mach-tegra/include/mach/iomap.h | 69 +++++-
> arch/arm/mach-tegra/include/mach/irqs.h | 14 +-
> arch/arm/mach-tegra/include/mach/legacy_irq.h | 4 +
> arch/arm/mach-tegra/include/mach/pinmux-t2.h | 10 +
> arch/arm/mach-tegra/include/mach/powergate.h | 40 ++++
> arch/arm/mach-tegra/include/mach/suspend.h | 38 ++++
> arch/arm/mach-tegra/include/mach/system.h | 10 +-
> arch/arm/mach-tegra/include/mach/uncompress.h | 18 +--
> arch/arm/mach-tegra/irq.c | 186 ++++++++---------
> arch/arm/mach-tegra/legacy_irq.c | 109 ++++++++++-
> arch/arm/mach-tegra/pinmux-t2-tables.c | 26 ++-
> arch/arm/mach-tegra/powergate.c | 212 +++++++++++++++++++
> arch/arm/mach-tegra/tegra2_clocks.c | 264 ++++++++++++++++++++++--
> arch/arm/mach-tegra/timer.c | 61 ++++++-
> 22 files changed, 1212 insertions(+), 291 deletions(-)
>
I pushed this patch set to tegra/for-next, with minor fixups from
Stephen Warren.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 28932] new avivo PLL calculation in Radeon driver fails with certain modelines
From: bugzilla-daemon @ 2011-02-12 8:51 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-28932-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=28932
--- Comment #1 from Alex Deucher <alexdeucher@gmail.com> 2011-02-12 08:51:26 ---
Created an attachment (id=47492)
--> (https://bugzilla.kernel.org/attachment.cgi?id=47492)
possible fix
This patch should fix it. The post divider was overflowing.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
--
^ permalink raw reply
* [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
From: Albert ARIBAUD @ 2011-02-12 8:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201102112357.58522.Aaron.Williams@caviumnetworks.com>
Le 12/02/2011 08:57, Aaron Williams a ?crit :
>> The CFI query is normal for a x16 device: byte address 0xAA is word
>> address 0x55, which is what is expected from a x16 device in x8 mode as
>> in x16 mode.
>>
>> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
>>
>> Amicalement,
> You mean like this?
>
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa
> Octeon ebb6300(ram)# mw.b 0x1f400555 0x55
> Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90
> Octeon ebb6300(ram)# md.b 0x1f400000 0
> Octeon ebb6300(ram)# md.b 0x1f400000 1
> 1f400000: 01 .
> Octeon ebb6300(ram)# md.b 0x1f400002 1
> 1f400002: 7e ~
> Octeon ebb6300(ram)# md.b 0x1f400004 1
> 1f400004: 00 .
> Octeon ebb6300(ram)# md.b 0x1f400005 1
> 1f400005: 00 .
> Octeon ebb6300(ram)# md.b 0x1f400006 1
> 1f400006: 1a .
> Octeon ebb6300(ram)# md.b 0x1f400008 1
> 1f400008: 00 .
> Octeon ebb6300(ram)# md.b 0x1f40000a 1
> 1f40000a: 00 .
> Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> Octeon ebb6300(ram)# md.b 0x1f400020
> 1f400020: 51 Q
> Octeon ebb6300(ram)# md.b 0x1f400022
> 1f400022: 52 R
> Octeon ebb6300(ram)# md.b 0x1f400024
> 1f400024: 59 Y
> Octeon ebb6300(ram)# md.b 0x1f400026
> 1f400026: 02 .
> Octeon ebb6300(ram)# md.b 0x1f400028
> 1f400028: 00 .
>
> -Aaron
No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20'
once in CFI QRY mode, that is:
mw.b 0x1f400000 0xf0
mw.b 0x1f4000AA 0x98
md.b 0x1f400020 20
Amicalement,
--
Albert.
^ permalink raw reply
* [PATCH] MAINTAINERS: Add entry for GPIO subsystem
From: Grant Likely @ 2011-02-12 8:48 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds, linux-kernel, Arnd Bergmann
I'll probably regret this....
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
MAINTAINERS | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1af022e..2f61f67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2768,6 +2768,15 @@ F: Documentation/isdn/README.gigaset
F: drivers/isdn/gigaset/
F: include/linux/gigaset_dev.h
+GPIO SUBSYSTEM
+M: Grant Likely <grant.likely@secretlab.ca>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+T: git git://git.secretlab.ca/git/linux-2.6.git
+F: Documentation/gpio/gpio.txt
+F: drivers/gpio/
+F: include/linux/gpio*
+
GRETH 10/100/1G Ethernet MAC device driver
M: Kristoffer Glembo <kristoffer@gaisler.com>
L: netdev@vger.kernel.org
^ permalink raw reply related
* RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Santosh Shilimkar @ 2011-02-12 8:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: Anand Gadiyar, Russell King - ARM Linux, linux-arm-kernel,
linux-omap, Keshava Munegowda, Felipe Balbi
In-Reply-To: <cace62268ad657586f07ecbb0e6a99ab@mail.gmail.com>
Tony,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Thursday, February 03, 2011 2:13 PM
> To: Tony Lindgren
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Thursday, February 03, 2011 1:19 AM
> > To: Santosh Shilimkar
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > >
> > > > It's a ES1.0 blaze, with the patch below it reboots early
> > > > during the boot. I also have to disable omap_l2_cache_init
> > > > on this board to get it to boot.
> > > >
> > > Do you still get this problem with 'omap_l2_cache_init' ?
> > > As reported earlier, we don't see this issue on ES1.0
> > > SDP.
> >
> > Yeah I do, it rarely makes it to the userspace. Works reliably
> > if I disable omap_l2_cache_init.
> >
> Ok. I shall try few experiments and try to reproduce it
Not sure if it's the same issue but I managed to reproduce the
issue on ES2.0 itself. And after some experiments, it boiled
down to the V6 and V7 issue. By disabling OMAP2 from the build,
everything was fine again.
Regards,
Santosh
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Santosh Shilimkar @ 2011-02-12 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cace62268ad657586f07ecbb0e6a99ab@mail.gmail.com>
Tony,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Thursday, February 03, 2011 2:13 PM
> To: Tony Lindgren
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony at atomide.com]
> > Sent: Thursday, February 03, 2011 1:19 AM
> > To: Santosh Shilimkar
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > >
> > > > It's a ES1.0 blaze, with the patch below it reboots early
> > > > during the boot. I also have to disable omap_l2_cache_init
> > > > on this board to get it to boot.
> > > >
> > > Do you still get this problem with 'omap_l2_cache_init' ?
> > > As reported earlier, we don't see this issue on ES1.0
> > > SDP.
> >
> > Yeah I do, it rarely makes it to the userspace. Works reliably
> > if I disable omap_l2_cache_init.
> >
> Ok. I shall try few experiments and try to reproduce it
Not sure if it's the same issue but I managed to reproduce the
issue on ES2.0 itself. And after some experiments, it boiled
down to the V6 and V7 issue. By disabling OMAP2 from the build,
everything was fine again.
Regards,
Santosh
^ permalink raw reply
* RE: [PATCH] x86: suppress HPET broadcast initialization in the presence of ARAT
From: Wei, Gang @ 2011-02-12 8:46 UTC (permalink / raw)
To: Keir Fraser, Jan Beulich, xen-devel@lists.xensource.com; +Cc: Wei, Gang
In-Reply-To: <C97BE8BA.133DE%keir@xen.org>
Keir Fraser wrote on 2011-02-12:
> On 12/02/2011 07:15, "Wei, Gang" <gang.wei@intel.com> wrote:
>> Jan Beulich wrote on 2011-02-10:
>>> This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0,
>>> noticing that all this setup is pointless when ARAT support is
>>> there, and knowing that on SLED11's native kernel it has actually
>>> caused S3 resume issues.
>>
>> Although this patch was already checked in, I still have to say it
>> is not necessary for Xen. Because hpet_broadcast_init() fn is only
>> called if (xen_cpuidle && !boot_cpu_has(X86_FEATURE_ARAT)) in
>> disable_pit_irq(). Of course I agree to keep it as a never used double check.
>
> Hmm I didn't spot that. Actually it is part of a more complex series
> of checks in the caller, so I wonder whether repeating just that one
> check in the function itself really makes much sense. I'm somewhat inclibned to revert it.
Revert it would be better.
Jimmy
^ permalink raw reply
* Re: [lm-sensors] [PATCH] libsensors: Add support for humidity
From: Jean Delvare @ 2011-02-12 8:44 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20110210054256.GA23546@ericsson.com>
On Fri, 11 Feb 2011 10:04:11 -0800, Guenter Roeck wrote:
> On Thu, Feb 10, 2011 at 07:08:10AM -0500, Guenter Roeck wrote:
> > On Thu, Feb 10, 2011 at 03:20:20AM -0500, Jean Delvare wrote:
> > > Hi Guenter,
> > >
> > > On Wed, 9 Feb 2011 21:42:56 -0800, Guenter Roeck wrote:
> > > > This patch adds support for humidity sensors to libsensors.
> > >
> > > Maybe it's a little late to discuss this now that humidity[1-*]_input
> > > is already described in Documentation/hwmon/sysfs-interface, but... do
> > > humidity sensors really belong to the hardware monitoring framework?
> > > What are the use cases of these sensors in practice?
> > >
> > > We let the accelerometer drivers slip in in the past (thankfully
> > > without documenting their attributes), and now we have a hard time
> > > getting them moved to the right place. I wouldn't want to do the same
> > > mistake with humidity sensors. My feeling is that they don't belong to
> > > hwmon.
> > >
> > The argument is that humidity is an environmental parameter which does
> > affect system operation, and thus it does belong to the hwmon framework.
> > I don't know what the existing/supported sensors are used for, but could
> > well imagine one in an industrial computer used to ensure that the system
> > isn't running in too much humidity.
>
> Copying Jonathan for additional comments.
>
> I did some search on the web, and noticed that many environmental monitoring
> systems for server environments include humidity sensors, and it is often listed
> at the same level of importance as temperature sensors.
Feel free to commit this patch then, if you're confident this is the
right thing to do.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH] git-gui: give more advice when detaching HEAD
From: Junio C Hamano @ 2011-02-12 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7vzkq1y8dv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> You only need to dig until you hit a merge base, no?
> ...
> And merge-base has an interface to compute exactly that, I think.
Ah, forget "merge-base". In the kernel repository, the very old "v2.6.12"
will participate in the (imaginary) merge across all the refs, and
computing merge-base means we need to traverse down to it.
We only need to prime a "struct revisions" with the detached HEAD as the
sole positive, and the refs as negatives (i.e. UNINTERESTING), and walk
the history the usual way, until we either
(1) see HEAD painted uninteresting; or
(2) the queue becomes all uninteresting.
As soon as (1) happens, we know the HEAD is reachable from some ref, and
we can immediately stop. When (2) happens, we inspect the HEAD again and
if it is painted uninteresting then we know HEAD is reachable from some
ref. Otherwise HEAD will become dangling when you leave it.
That way, the traversal will terminate much sooner than computing the true
merge base.
^ permalink raw reply
* [U-Boot] [PATCH 0/5] USB RNDIS gadget support
From: Remy Bohmer @ 2011-02-12 8:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1297437515-4069-1-git-send-email-vkuzmichev@mvista.com>
Hi,
2011/2/11 Vitaly Kuzmichev <vkuzmichev@mvista.com>:
> The patch series integrates RNDIS protocol support
> into the current U-Boot USB gadget stack to talk with Windows host.
>
> Synced with linux-2.6.26 version (latest one that has simple,
> non-composite gadget architecture), therefore I've kept checkpatch
> warnings about typedefs and >80 character lines, but I'm glad
> to discuss necessity and ways to fix them.
>
> Actually this protocol should not require to make any changes in
> existing USB device controller drivers.
>
> And sorry for the huge RNDIS patch.
>
> Vitaly Kuzmichev (5):
> ?USB-CDC: handle interrupts after dropped pullup
> ?USB-CDC: Port struct net_device_stats
> ?USB-CDC: Move struct declaration before its use
> ?USB: Add USB RNDIS gadget protocol
> ?USB-RNDIS: Send RNDIS state on disconnecting
>
> ?drivers/usb/gadget/Makefile | ? ?1 +
> ?drivers/usb/gadget/ether.c ?| ?777 ++++++++++++++++++++++---
> ?drivers/usb/gadget/ndis.h ? | ?217 +++++++
> ?drivers/usb/gadget/rndis.c ?| 1317 +++++++++++++++++++++++++++++++++++++++++++
> ?drivers/usb/gadget/rndis.h ?| ?260 +++++++++
> ?include/linux/netdevice.h ? | ? 65 +++
> ?include/linux/usb/cdc.h ? ? | ? ?6 +-
> ?7 files changed, 2550 insertions(+), 93 deletions(-)
> ?create mode 100644 drivers/usb/gadget/ndis.h
> ?create mode 100644 drivers/usb/gadget/rndis.c
> ?create mode 100644 drivers/usb/gadget/rndis.h
> ?create mode 100644 include/linux/netdevice.h
First impression: Looks good!
I will look into the details later... I will come back on it in a
couple of days. (it is quite huge ;-) )
Kind regards,
Remy
^ permalink raw reply
* GET BACK TO ME ASAP 1
From: Hassan Bin Ismail @ 2002-01-23 20:32 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
HASSAN ISMAIL & ASSOCIATES.
NO. 122A, 1ST FLOOR JALAN
SULTANAH BATU PAHAT 80000
JOHOR BAHRU MALAYSIA.
(PRIVATE/CONFIDENTIAL)
My name is Hassan Bin Ismail,a legal practitioner with Hassan Ismail & Associates. A deceased client of mine, that shares the same last name as yours,who died as a result of a heart related condition in 18th November 2004.
I have contacted you to assist in distributing the money left behind by my late client(US$19,000,000.00) Nineteen Million United States Dollars is lodged in the bank.
Sincerely yours.
Barr.Hassan Bin Ismail (Esq)
(Attorney at Law
^ permalink raw reply
* mc13xxx-core, support for i2c, V4
From: Grant Likely @ 2011-02-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294119299-18352-1-git-send-email-marc@cpdesign.com.au>
On Tue, Jan 04, 2011 at 04:34:55PM +1100, Marc Reilly wrote:
> Hi,
>
> These patches add i2c support for the mc13xxx-core drive. For v4 I've tried to take
> in all previous comments, hopefully making it better to follow, and bisectable.
This series looks okay to me. Since this is audio drivers, I expect
that it would best be taken via the ASoC tree? Have you sent it to
Mark Brown and the ALSA list for review?
g.
^ permalink raw reply
* Re: mc13xxx-core, support for i2c, V4
From: Grant Likely @ 2011-02-12 8:40 UTC (permalink / raw)
To: Marc Reilly
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1294119299-18352-1-git-send-email-marc-DtE7ei5U7Kg0n/F98K4Iww@public.gmane.org>
On Tue, Jan 04, 2011 at 04:34:55PM +1100, Marc Reilly wrote:
> Hi,
>
> These patches add i2c support for the mc13xxx-core drive. For v4 I've tried to take
> in all previous comments, hopefully making it better to follow, and bisectable.
This series looks okay to me. Since this is audio drivers, I expect
that it would best be taken via the ASoC tree? Have you sent it to
Mark Brown and the ALSA list for review?
g.
^ permalink raw reply
* Re: grep --no-index and pathspec
From: Nguyen Thai Ngoc Duy @ 2011-02-12 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Lars Noschinski, git
In-Reply-To: <7vvd0py7xy.fsf@alter.siamese.dyndns.org>
On Sat, Feb 12, 2011 at 3:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> NOTE! This does *not* obviate the need for the caller to do the *exact*
>> pathspec match later. It's a first-level filter on "read_directory()", but
>> it does not do the full pathspec thing. Maybe it should. But in the
>> meantime,...
>
> I was around back then, so I know how the code came about ;-)
>
> The pieces used in the pathspec limiting logic have been restructured well
> enough that I suspect it may now be feasible for us to revisit the "Maybe
> it should" part in the above quote. Thanks to nd/struct-pathspec topic, I
> think we are already half-way there.
I was around too, just oblivious about things. I can look into that.
Need to think a bit how to save what pathspecs are "seen", so that
prune_directory() in builtin/add.c can be dropped.
--
Duy
^ permalink raw reply
* Genius TVGo DVB-T03 has not Afatech chipset but rtl2832u
From: Erik Dobák @ 2011-02-12 8:39 UTC (permalink / raw)
To: video4linux-list
In-Reply-To: <AANLkTimKGmSdEuJFg0aRn=juEx91wy+LJp--WpMXVe_o@mail.gmail.com>
Please make a comment in this page:
http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices
as i bought this one and hoped my kernel 2.6.36 will support it. it does
not.
when i opened the usb stick there was the rtl2832u chip inside.
cheers
E
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
^ permalink raw reply
* Re: [PATCH v4 1/3]mmc: set max_discard_sectors value for mmc queue
From: Arnd Bergmann @ 2011-02-12 8:38 UTC (permalink / raw)
To: Chuanxiao Dong; +Cc: linux-mmc, cjb, linux-kernel, akpm, adrian.hunter
In-Reply-To: <20110212062214.GB25519@intel.com>
On Saturday 12 February 2011 07:22:14 Chuanxiao Dong wrote:
> max_discard_sectors value is UINT_MAX which means kernel block layer can pass
> down unlimited sectors to MMC driver to erase. But erasing so many sectors may
> delay some other important I/O requests. This is not preferred.
>
> So use 'pref_erase' to set a suitable max_discard_sectors value for mmc queue to
> avoid erasing too many sectors at one time.
>
> Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
I'm not sure about this one. pref_erase on SDHC cards should be the *minimum*
unit you can erase in one request, not the maximum. Erasing an arbitrary
number of allocation units on an SDHC card should complete almost instantly,
because it only needs to update a single table with the allocation units.
Discarding partial allocation units will take a lot longer, because the
card then has to copy over the remaining blocks.
Arnd
^ permalink raw reply
* Re: t7006 sometimes hangs in cronjobs on OS X
From: Jonathan Nieder @ 2011-02-12 8:37 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, git
In-Reply-To: <20110212051239.GA31606@sigill.intra.peff.net>
Jeff King wrote:
> 1. In your Copy.pm log above, it says read gives it 4 characters. But
> "hi\n" has only 3.
Yes, it's "hi\r\n".
> I would first try this patch:
[...]
> +++ b/t/test-terminal.perl
> @@ -15,6 +15,7 @@ sub start_child {
> open STDOUT, ">&", $out;
> open STDERR, ">&", $err;
> close $out;
> + close $err;
> exec(@$argv) or die "cannot exec '$argv->[0]': $!"
Good idea. No change, alas (and likewise with the change to close
the pty master in the child). It seems I have some reading to do.
Jonathan
> and then try this more drastic one:
[...]
> --- a/t/test-terminal.perl
> +++ b/t/test-terminal.perl
> @@ -12,9 +12,12 @@ sub start_child {
[...]
> @@ -69,7 +72,7 @@ if ($#ARGV < 1) {
> }
> my $master_out = new IO::Pty;
> my $master_err = new IO::Pty;
> -my $pid = start_child(\@ARGV, $master_out->slave, $master_err->slave);
> +my $pid = start_child(\@ARGV, $master_out, $master_err);
Runs through ~1000 iterations instead of 100 before hanging.
> Also, I don't know what kind of support you have for stuff like lsof,
> but in theory we should be able to get a hung process, find the open
> descriptor for the pty using lsof, match that descriptor with the other
> end of the pty, and then see which processes have that pty still open.
Trial 1
~~~~~~~
PID 49145 (which has successfully pumped stdout):
0 /dev/ttys001
1 write-only out.1707
2 write-only out.1707
3 /dev/ptmx @ offset 4
5 write-only debug.log
PID 49147 (which is stuck in sysread trying to read stderr):
0 /dev/ttys001
1 write-only out.1707
2 write-only out.1707
5 write-only debug.log
6 /dev/ptmx @ offset 0
Trial 2
~~~~~~~
PID 51091 (which is stuck in sysread trying to read stdout):
0 /dev/ttys001
1 write-only out.2017
2 write-only out.2017
3 /dev/ptmx @ offset 4
5 write-only debug.log
PID 591093 (which successfully pumped stderr) is a zombie
(echo was a zombie in both cases.)
>> Redirecting stderr by using 'xsendfile("elsewhere", $err);' avoids
>> trouble.
>
> That seems doubly weird, since you are changing the _output_, not the
> input. But the input is what is causing the hang.
False alarm --- after about 2500 iterations it hangs. Probably just
changed the timing.
>> Sometimes output includes some streams of null bytes, which makes me
>> suspect something awry in the kernel.
>
> Yuck.
Was my mistake --- apparently I was writing files with holes. Now I
send debug output to a separate file with O_APPEND and it hasn't
happened again.
^ permalink raw reply
* Re: [PATCH v4 2/3]mmc: enable TRIM/ERASE caps for SDHCI host
From: Arnd Bergmann @ 2011-02-12 8:34 UTC (permalink / raw)
To: Chuanxiao Dong; +Cc: linux-mmc, cjb, linux-kernel, akpm, adrian.hunter
In-Reply-To: <20110212062220.GC25519@intel.com>
On Saturday 12 February 2011 07:22:20 Chuanxiao Dong wrote:
> SDHCI host controller has TRIM/ERASE capability, enable these caps for erasing
> purpose.
>
> ERASE command needs R1B response. So for such command with busy signal, before
> sending command, SDHCI host driver will simply set a maximum value for timeout
> control register which is safe to use.
>
> Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Great stuff! I needed this for a project of mine, but couldn't
get it to work reliably without knowing about the timeout logic.
I think, almost no mmc controllers advertice MMC_CAP_ERASE today,
which is a real shame, given that it's extremely useful for performance.
Arnd
^ permalink raw reply
* Re: [PATCH] mcspi: Add support for GPIO chip select lines
From: Grant Likely @ 2011-02-12 8:33 UTC (permalink / raw)
To: Ben Gamari
Cc: beagleboard, linux-omap, David Brownell, Michael Hennerich,
spi-devel-general, Eric Miao
In-Reply-To: <878vzfr9h7.fsf@gmail.com>
On Fri, Dec 24, 2010 at 01:05:56AM -0500, Ben Gamari wrote:
> On Thu, 23 Dec 2010 20:28:19 -0700, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Thu, Dec 23, 2010 at 09:27:20PM -0500, Ben Gamari wrote:
> > > I understand your concerns, but I'm not sure how to satisfy them without
> > > crippling the design's ability to accomodate my use-case. I can't pass a
> > > GPIO line per spi_board_info since in my case of a multiplexed CS
> > > configuration a single pin's state does not uniquely determine the
> > > desired CS. The only other option I can think of is that we somehow
> > > provide a list of GPIOs for each bus and map the CS numbers to
> > > permutations of GPIO states. Unfortunately, I don't know of any suitable
> > > structure to put this GPIO list in. Perhaps I'm missing something obvious?
> >
> > Close, but not quite. Assign one gpio number to each cs state, and
> > write a gpio controller driver that maps the linux-gpio number to the
> > physical gpio state permutation. The mapping from gpio# to ss# is
> > 1:1, but the driver behind the gpio# can do whatever you need it to
> > do.
> >
> I see. I'm still not convinced that this is the route to take,
> however. It seems like this virtual gpio interface is not only pretty
> clunky (simple board file glue turns into an entire gpio chip driver),
> it seems like this is a very inaccurate and not very useful way to
> expose a multiplexed CS configuration; e.g. what is this chip driver to
> do if the user tries to set two CS pins at once?
(Sorry for the really laggy reply)
I don't see it being that big a deal. gpio drivers are pretty
lightweight and it is fine to have domain-specific limitations on how
gpios for a particular "gpio controller" behave. In your example, if
the hardware doesn't support enabling 2 CS pins at once, then you make
a choice, either setting one when the other is already set simply does
not work; or it could reset the other state. Either choice would be
fine. The SPI driver must do the right thing regardless and deselect
the previous CS line before enabling a new one.
The other alternative would be to implement a new SPI chipselect
common infrastructure, but IMO, that would just end up looking like a
duplication of the gpio infrastructure.
Regardless, my point still stands, platform callbacks for what amounts
to gpio manipulations doesn't make a whole lot of sense.
> Is there precedent for
> using the GPIO subsystem in this way?
Yes, in drivers/spi look at mpc52xx_spi.c, davinci_spi.c, ath79_spi.c,
atmel_spi.c, and many more. Grep for gpio in drivers/spi.
g.
^ permalink raw reply
* [PATCH v2] distro/jlime-2010.1.conf: cleaned up RDEPENDS, beefed up FEATURES.
From: Filip Zyzniewski @ 2011-02-12 8:29 UTC (permalink / raw)
To: openembedded-devel, kristoffer.ericson
In-Reply-To: <1297461882-5965-1-git-send-email-filip.zyzniewski@gmail.com>
tslib and dialog should be pulled in by appropiate dependencies and
wireless-tools comes from wifi in DISTRO_FEATURES.
Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
---
conf/distro/jlime-2010.1.conf | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/conf/distro/jlime-2010.1.conf b/conf/distro/jlime-2010.1.conf
index 2bc3d10..a3ec20e 100644
--- a/conf/distro/jlime-2010.1.conf
+++ b/conf/distro/jlime-2010.1.conf
@@ -23,8 +23,7 @@ OVERRIDES .= ":jlime"
#
# What we want on the bootstrap image (extra)
#
-DISTRO_EXTRA_RDEPENDS = "wireless-tools nano keymaps tslib-calibrate \
- console-tools tslib-tests dialog"
+DISTRO_EXTRA_RDEPENDS = "nano keymaps console-tools"
#
# Our Image files should look abit better.
@@ -67,7 +66,7 @@ TARGET_FPU_armeb = "soft"
TARGET_FPU_mipsel = "soft"
TARGET_FPU_mips = "soft"
-DISTRO_FEATURES += " eabi "
+DISTRO_FEATURES += "eabi wifi"
LIBC ?= "eglibc"
PREFERRED_PROVIDER_virtual/libc = "${LIBC}"
--
1.7.1
^ permalink raw reply related
* Dear Friend,
From: Paul Compaore @ 2011-02-12 8:27 UTC (permalink / raw)
Dear Friend,
I am Mr.Paul Compaore; I am in charge of auditing section in Banque Internationale Du Burkina (BIB). I need your urgent assistance to transfer the sum of ($11.3 million to your account. I will send you full details on how the business will be executed and also note that you will receive 50% of the above mentioned amount if you agree to assist me execute this business transaction. If you are interested and capable to handle this business transaction, come up with the information's shown below:-
1). Your full name:
2). Your contact cell phone number:
3). Your age:
4). Your sex:
5). Your occupations:
6). Your country and city:
As soon as possible all these information's is submitted to me immediately i will send you full details of this business transaction on the receipt of your response.Reply to my private email: paulcompaore14@gmail.com
Thanks.
Mr Paul Compaore
^ permalink raw reply
* Dear Friend,
From: Paul Compaore @ 2011-02-12 8:27 UTC (permalink / raw)
Dear Friend,
I am Mr.Paul Compaore; I am in charge of auditing section in Banque Internationale Du Burkina (BIB). I need your urgent assistance to transfer the sum of ($11.3 million to your account. I will send you full details on how the business will be executed and also note that you will receive 50% of the above mentioned amount if you agree to assist me execute this business transaction. If you are interested and capable to handle this business transaction, come up with the information's shown below:-
1). Your full name:
2). Your contact cell phone number:
3). Your age:
4). Your sex:
5). Your occupations:
6). Your country and city:
As soon as possible all these information's is submitted to me immediately i will send you full details of this business transaction on the receipt of your response.Reply to my private email: paulcompaore14@gmail.com
Thanks.
Mr Paul Compaore
^ permalink raw reply
* Re: grep --no-index and pathspec
From: Junio C Hamano @ 2011-02-12 8:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Michael J Gruber, Lars Noschinski, git
In-Reply-To: <AANLkTikG1C=7NRGoi+HWz8rE9RN8-pF6o0=S29GZA3eK@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2011/2/12 Junio C Hamano <gitster@pobox.com>:
>>
>> The function fill_directory() already takes a pathspec, albeit in the
>> degenerate "const char **" form. Why does its output need further
>> filtering?
>
> Because it was designed so? Quotes from 9fc42d6 (Optimize directory
> listing with pathspec limiter. - 2007-03-30), which added
> simplify_away(), the function that does pathspec filtering for
> fill_directory():
>
> NOTE! This does *not* obviate the need for the caller to do the *exact*
> pathspec match later. It's a first-level filter on "read_directory()", but
> it does not do the full pathspec thing. Maybe it should. But in the
> meantime,...
I was around back then, so I know how the code came about ;-)
The pieces used in the pathspec limiting logic have been restructured well
enough that I suspect it may now be feasible for us to revisit the "Maybe
it should" part in the above quote. Thanks to nd/struct-pathspec topic, I
think we are already half-way there.
^ permalink raw reply
* Re: [PATCH] git-gui: give more advice when detaching HEAD
From: Jeff King @ 2011-02-12 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vzkq1y8dv.fsf@alter.siamese.dyndns.org>
On Sat, Feb 12, 2011 at 12:17:16AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Is it that cheap? A full reachability check for something that is not in
> > any ref would involve going to the roots, wouldn't it?
>
> You only need to dig until you hit a merge base, no?
Hmm, yeah, you're right. In the worst case of reachability checks, you
would share no ancestry and go to the roots searching for the merge
base, but of course that is very unlikely to be the case here. So it
should be much cheaper.
> And merge-base has an interface to compute exactly that, I think.
Want to do a proof-of-concept patch? Then we can get some real timings.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.