* [U-Boot] Failed to apply patch
From: Sadashiva @ 2011-10-24 7:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110181413.20478.sr@denx.de>
Hi Sir,
I downloaded the latest version of u-boot source code of version number
u-boot-2011.03.tar.bz2.
from ftp://ftp.denx.de/pub/u-boot/ website and the MPL patches for
this from the website
http://www.mpl.ch/t2722.html
Latest MPL supported version. Patches are available here: MPL
patches
But when I apply the patch example
test at test-laptop:~/toolchain_2011/u-boot-2011.03$patch -p1 <
u-boot-2011.03.mpl-patches
I am getting failed message like.
patching file MAINTAINERS
Hunk #1 FAILED at 342.
1 out of 1 hunk FAILED -- saving rejects to file MAINTAINERS.rej
patching file arch/powerpc/cpu/mpc83xx/fdt.c
Hunk #1 FAILED at 50.
Hunk #2 FAILED at 132.
2 out of 2 hunk FAILED -- saving rejects to file
arch/powerpc/cpu/mpc83xx/fdt.c.rej
patching file board/mpl/common/common_util.c
Hunk #1 FAILED at 33.
Hunk #2 FAILED at 161.
Hunk #3 FAILED at 189.
Hunk #4 FAILED at 198.
Hunk #5 FAILED at 211.
Hunk #6 FAILED at 243.
Hunk #7 FAILED at 253.
Hunk #8 FAILED at 281.
Hunk #9 FAILED at 306.
Hunk #10 FAILED at 337.
Hunk #11 FAILED at 370.
Hunk #12 FAILED at 389.
Hunk #13 FAILED at 428.
Hunk #14 FAILED at 472.
Hunk #15 FAILED at 485.
Hunk #16 FAILED at 507.
Hunk #17 FAILED at 537.
Hunk #18 FAILED at 547.
Hunk #19 FAILED@577.
19 out of 19 hunk FAILED -- saving rejects to file
board/mpl/common/common_util.c.rej
patching file board/mpl/common/flash.c
Reversed (or previous applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
skipping patch.
Can I get any help on this failed issue.
Thanking you in advance.
Best Regards,
Sadashiv
^ permalink raw reply
* serial-console: IMAGE_FEATURE, MACHINE_FEATURE or DISTRO_FEATURE?
From: Koen Kooi @ 2011-10-24 7:27 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi,
Otavio is cleaning up systemd in meta-oe to work with his initramfs setup and we stumbled onto a challenge that we'd like some more feedback on.
The old sysvinit recipes always hardcode a serial getty into inittab, systemd installs a getty@<port>.service file instead. Otavio doesn't need (or want) a getty on serial in his setup, but I need (and want) it on all my setups. So we agreed that it needs to be a feature :)
I nitially suggested MACHINE_FEATURE, which Otavio implemented here: http://patchwork.openembedded.org/patch/13713/ , but I'm having second thoughs about it and am leaning toward an IMAGE_FEATURE instead. Since this involves *_FEATURE and we want systemd to move into oe-core eventually I'm moving the discussion from OE-devel to OE-core. Not much discussion has been going on, so I hope we'll get some more feedback here. I'll try to buttonhole some more OE developers at ELC and report back as well.
regards,
Koen
^ permalink raw reply
* Votre devis alarme est disponible
From: Votre expert protection parzabaion @ 2011-10-24 7:33 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Si vous ne pouvez pas visualiser ce message, consulter notre version en
ligne.
Vous avez la possibilité de vous retirer de notre liste d'envoi de
mails par l'intermediaire de ce raccourci
Service personnalisé
[IMG] Alarme haute sécurité
Système Alarme Protection 24/24h
Télésurveillance Contrôle à distance
Détecteurs d'images
MES DEVIS GRATUITS ICI [IMG] [IMG] [IMG] [IMG]
[IMG] [IMG]
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
^ permalink raw reply
* Re: [PATCH] read-cache.c: fix index memory allocation
From: Junio C Hamano @ 2011-10-24 7:28 UTC (permalink / raw)
To: René Scharfe; +Cc: Jeff King, John Hsing, Matthieu Moy, git
In-Reply-To: <4EA4B8E7.5070106@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> t/t7510-status-index.sh | 50 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 53 insertions(+), 3 deletions(-)
> create mode 100755 t/t7510-status-index.sh
> diff --git a/t/t7510-status-index.sh b/t/t7510-status-index.sh
> new file mode 100755
> index 0000000..bca359d
> --- /dev/null
> +++ b/t/t7510-status-index.sh
> @@ -0,0 +1,50 @@
Hmm, I cannot seem to make this fail this test without the fix on my
Fedora 14 i686 VM when applied to v1.7.6.4 (estimation code originates
cf55870 back in v1.7.6.1 days), but it does break on 'master'.
By the way, I'll move this to 7511.
Also would a patch like this help?
-- >8 --
Subject: [PATCH] read_index(): die on estimation error
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
read-cache.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 0a64103..2926615 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1270,6 +1270,7 @@ int read_index_from(struct index_state *istate, const char *path)
int fd, i;
struct stat st;
unsigned long src_offset, dst_offset;
+ size_t bulk_alloc_size;
struct cache_header *hdr;
void *mmap;
size_t mmap_size;
@@ -1315,7 +1316,8 @@ int read_index_from(struct index_state *istate, const char *path)
* has room for a few more flags, we can allocate using the same
* index size
*/
- istate->alloc = xmalloc(estimate_cache_size(mmap_size, istate->cache_nr));
+ bulk_alloc_size = estimate_cache_size(mmap_size, istate->cache_nr);
+ istate->alloc = xmalloc(bulk_alloc_size);
istate->initialized = 1;
src_offset = sizeof(*hdr);
@@ -1331,7 +1333,9 @@ int read_index_from(struct index_state *istate, const char *path)
src_offset += ondisk_ce_size(ce);
dst_offset += ce_size(ce);
+ if (bulk_alloc_size <= dst_offset)
+ die("cache size estimation error");
}
istate->timestamp.sec = st.st_mtime;
istate->timestamp.nsec = ST_MTIME_NSEC(st);
--
1.7.7.1.504.gcc718
^ permalink raw reply related
* Re: qcow2 eating up space when formattng Centos
From: Philipp Hahn @ 2011-10-24 7:17 UTC (permalink / raw)
To: day knight; +Cc: kvm
In-Reply-To: <CAHaoJr+tMksHPMEYU49H9BJ5yH11AY_PzKa0OWYnE2bVPObBcg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
Hello Anonnymous,
On Monday 24 October 2011 03:22:15 day knight wrote:
> I am not sure if this is the right behaviour but qcow2 image seems to
> grow when Centos is only formatting the image. I mean it goes upto 30
> Gig once evrything is formatted and installed and it is minimal Centos
> install with no gui or apps just baseline.
>
> OS = Centos5
> Virtualization: KVM
> Total Qcow2 Image Created = 1TB
>
> Once Centos is installed the qcow2 image shows as around 30 Gig. I
> have done several install and they were all less than 4 gig or even
> lesser but this seems to not make sense
>
> Can someone please explain what is going on?
You didn't tell which file system you're using. ext3 needs to initialize its
meta data (super blocks, inote tables), which are scattered all over the
image. Depending on your cluster size fpr the qcow2 file, each (small) write
takes the space of a full cluster. Add to that the meta-data needed by qcow2
itself (a two-level tree), 30 GiB seem to be okay.
You might want to try ext4 with "delayed allocation" (IMHO enabled by
default), which doesn't write all over the range, since initialization of the
superblock and inode tables is delayed until they are acually needed.
Sincerely
Philipp
--
Philipp Hahn Open Source Software Engineer hahn@univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Register cache different from the real register values
From: Leon Romanovsky @ 2011-10-24 7:26 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel
In-Reply-To: <20111023143754.GB23045@opensource.wolfsonmicro.com>
On Sun, Oct 23, 2011 at 16:37, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, Oct 23, 2011 at 04:14:07PM +0200, Leon Romanovsky wrote:
>> On Sun, Oct 23, 2011 at 15:51, Mark Brown
>
>> > Post your code for review and we
>> > might be able to spot something.
>
>> Our code is located at
>> http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/chromeos-ac100-2.6.38/sound/soc/codecs/alc5632.c
>
> Please post for upstream, it's much easier to review and ideally we
> could even get the driver merged.
>
>> > At a guess you're doing cache_only and
>> > something's going wrong there
>> I also tried to add codec->cache_sync = 1 to the _probe function, but
>> without luck.
>> http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/chromeos-ac100-2.6.38/sound/soc/codecs/alc5632.c#line998
>
> You should only set cache_sync if you dirty the cache and then you need
> to call cache_sync() at some point to actually sync the cache.
>
>> > the register defaults are wrong or the
>
>> Our style is a little different, because it is a port from the
>> android, we will be change it later, before merging into the mainline
>> to be more convenient.
>> http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/chromeos-ac100-2.6.38/sound/soc/codecs/alc5632.c#line1023
>
> Android is using the same kernel - there's no differences introduced by
> Android here. If you're seeing differences they're driver quality
> issues (probably caused by not being mainline).
>
> Looking briefly at the code that android_init() function is just broken
> and should be removed, any missing control should be implemented in the
> driver. The fill_cache() function looks suspect also - in general all
> the code peering directly into the register cache data structure smells
> bad. You should have register defaults hard coded into the driver which
> reflect the chip defaults so when we reset we know that's where the chip
> is at.
>
> Another thing to check is that the registers in the chip aren't
> volatile, if the chip can change register values underneath the driver
> then obviously things might get confused. Multiple copies of the same
> control are a common culprit.
>
Thanks, I'll post the patches, as soon as possible.
--
Leon Romanovsky | Independent Linux Consultant
www.leon.nu | leon@leon.nu
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-24 7:26 UTC (permalink / raw)
To: Mike Frysinger
Cc: Grant Likely, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <CAMjpGUe9abPsdWbum2MRzOV2b5_2FDqXZC-K0KThRA6MNTr4FA@mail.gmail.com>
On Sat, Oct 22, 2011 at 7:44 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
>> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
>>> 2011/9/30 Grant Likely:
>>> > I'm not convinced that the sysfs approach is
>>> > actually the right interface here (I'm certainly not a fan of the gpio
>>> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>>> > userspace i/f is hammered out.
>>>
>>> Actually, thinking about it I cannot see what would be wrong
>>> with /dev/gpio0 & friends in the first place.
>>>
>>> Using sysfs as swiss army knife for custom I/O does not
>>> seem like it would be long-term viable so thanks for this
>>> observation, and I think we need /dev/gpio* put on some
>>> mental roadmap somewhere.
>>
>> Agreed. I don't want to be in the situation we are now with GPIO,
>> where every time I look at the sysfs interface I shudder.
>
> the problem with that is it doesn't scale. if i have a device with
> over 150 GPIOs on the SoC itself (obviously GPIO expanders can make
> that much bigger), i don't want to see 150+ device nodes in /dev/.
> that's a pretty big waste. sysfs only allocates/frees resources when
> userspace actually wants to utilize a GPIO.
I was more thinking along the lines of one device per GPIO controller,
then you ioctl() to ask /dev/gpio0 how many pins it has or so.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-24 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMjpGUe9abPsdWbum2MRzOV2b5_2FDqXZC-K0KThRA6MNTr4FA@mail.gmail.com>
On Sat, Oct 22, 2011 at 7:44 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
>> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
>>> 2011/9/30 Grant Likely:
>>> >?I'm not convinced that the sysfs approach is
>>> > actually the right interface here (I'm certainly not a fan of the gpio
>>> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>>> > userspace i/f is hammered out.
>>>
>>> Actually, thinking about it I cannot see what would be wrong
>>> with /dev/gpio0 & friends in the first place.
>>>
>>> Using sysfs as swiss army knife for custom I/O does not
>>> seem like it would be long-term viable so thanks for this
>>> observation, and I think we need /dev/gpio* put on some
>>> mental roadmap somewhere.
>>
>> Agreed. ?I don't want to be in the situation we are now with GPIO,
>> where every time I look at the sysfs interface I shudder.
>
> the problem with that is it doesn't scale. ?if i have a device with
> over 150 GPIOs on the SoC itself (obviously GPIO expanders can make
> that much bigger), i don't want to see 150+ device nodes in /dev/.
> that's a pretty big waste. ?sysfs only allocates/frees resources when
> userspace actually wants to utilize a GPIO.
I was more thinking along the lines of one device per GPIO controller,
then you ioctl() to ask /dev/gpio0 how many pins it has or so.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next 0/5][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-10-24 7:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1319193121-2729-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 21 Oct 2011 03:31:56 -0700
> The following series contains updates to igbvf and igb.
> This version of the series contains the following changes:
>
> - igb 2 fixes (VFTA table, Alt. MAC addr) and move DMA coalescing init
> code into separate function
> - igbvf bump version and update identification strings
>
> The following are changes since commit :
>
> and are available in the git repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH 1/1] mmc: core: Use delayed work in clock gating framework
From: Linus Walleij @ 2011-10-24 7:23 UTC (permalink / raw)
To: Sujit Reddy Thumma; +Cc: linux-mmc, linux-arm-msm, cjb
In-Reply-To: <1319035713-4979-1-git-send-email-sthumma@codeaurora.org>
On Wed, Oct 19, 2011 at 4:48 PM, Sujit Reddy Thumma
<sthumma@codeaurora.org> wrote:
> Current clock gating framework disables the MCI clock as soon as the
> request is completed and enables it when a request arrives. This aggressive
> clock gating framework when enabled cause following issues:
>
> When there are back-to-back requests from the Queue layer, we unnecessarily
> end up disabling and enabling the clocks between these requests since 8 MCLK
> clock cycles is a very short duration compared to the time delay between
> back to back requests reaching the MMC layer. This overhead can effect the
> overall performance depending on how long the clock enable and disable
> calls take which is platform dependent. For example on some platforms we
> can have clock control not on the local processor, but on a different
> subsystem and the time taken to perform the clock enable/disable can add
> significant overhead.
OK I see the problem. At one point it was suggested to use the delayed
disable facilities in runtime PM for avoiding this, but it never materialized.
> Fix this by delaying turning off the clocks by posting request on
> delayed workqueue. Also cancel the unscheduled pending work, if any,
> when there is access to card.
(...)
> @@ -252,10 +252,11 @@ struct mmc_host {
> int clk_requests; /* internal reference counter */
> unsigned int clk_delay; /* number of MCI clk hold cycles */
> bool clk_gated; /* clock gated */
> - struct work_struct clk_gate_work; /* delayed clock gate */
> + struct delayed_work clk_gate_work; /* delayed clock gate */
> unsigned int clk_old; /* old clock value cache */
> spinlock_t clk_lock; /* lock for clk fields */
> struct mutex clk_gate_mutex; /* mutex for clock gating */
> +#define MMC_CLK_GATE_DELAY 50 /* in milliseconds*/
> #endif
What's the rationale of having this in the middle of the struct
in the .h-file?
Move it inside the #ifdef in host.c instead, and also provide
some rationale about the choice of 50 ms.
Maybe we should even provide a sysfs or debugfs entry for
tweaking that value, as has been suggested in the past.
However that's no big deal for me...
Do you have a patch to your msm_sdcc.c that enables the
gating to take effect as well? Does it solve the problems
pointed out by Russell when I tried the same type of patch
to mmci.c?
http://marc.info/?l=linux-mmc&m=129146545916794&w=2
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] KVM: VMX: fix incorrect operand
From: Zhao Jin @ 2011-10-24 7:21 UTC (permalink / raw)
To: avi, mtosatti; +Cc: linux-kernel, kvm
In-Reply-To: <1319440880-2610-1-git-send-email-cronozhj@gmail.com>
Should test save->ar for access rights.
Signed-off-by: Zhao Jin <cronozhj@gmail.com>
---
arch/x86/kvm/vmx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e65a158..62086da 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2544,7 +2544,7 @@ static void fix_pmode_dataseg(int seg, struct kvm_save_segment *save)
{
struct kvm_vmx_segment_field *sf = &kvm_vmx_segment_fields[seg];
- if (vmcs_readl(sf->base) == save->base && (save->base & AR_S_MASK)) {
+ if (vmcs_readl(sf->base) == save->base && (save->ar & AR_S_MASK)) {
vmcs_write16(sf->selector, save->selector);
vmcs_writel(sf->base, save->base);
vmcs_write32(sf->limit, save->limit);
--
1.7.5.4
^ permalink raw reply related
* [PATCH] KVM: MMU: fix the condition of syncing a new shadow page
From: Zhao Jin @ 2011-10-24 7:21 UTC (permalink / raw)
To: avi, mtosatti; +Cc: linux-kernel, kvm
In-Reply-To: <1319440880-2610-1-git-send-email-cronozhj@gmail.com>
Should be "or" since a new shadow page is synced if either it is
not leaf or there already exists another unsync shadow page with
the same gfn.
Signed-off-by: Zhao Jin <cronozhj@gmail.com>
---
arch/x86/kvm/mmu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d7e1694..f36de41 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1698,7 +1698,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
if (!direct) {
if (rmap_write_protect(vcpu->kvm, gfn))
kvm_flush_remote_tlbs(vcpu->kvm);
- if (level > PT_PAGE_TABLE_LEVEL && need_sync)
+ if (level > PT_PAGE_TABLE_LEVEL || need_sync)
kvm_sync_pages(vcpu, gfn);
account_shadowed(vcpu->kvm, gfn);
--
1.7.5.4
^ permalink raw reply related
* [PATCH] KVM: MMU: initialize sptes early
From: Zhao Jin @ 2011-10-24 7:21 UTC (permalink / raw)
To: avi, mtosatti; +Cc: linux-kernel, kvm
Otherwise, the following kvm_sync_pages() will see invalid sptes in a new
shadow page.
Signed-off-by: Zhao Jin <cronozhj@gmail.com>
---
arch/x86/kvm/mmu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 8e8da79..d7e1694 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1692,6 +1692,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
return sp;
sp->gfn = gfn;
sp->role = role;
+ init_shadow_page_table(sp);
hlist_add_head(&sp->hash_link,
&vcpu->kvm->arch.mmu_page_hash[kvm_page_table_hashfn(gfn)]);
if (!direct) {
@@ -1702,7 +1703,6 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
account_shadowed(vcpu->kvm, gfn);
}
- init_shadow_page_table(sp);
trace_kvm_mmu_get_page(sp, true);
return sp;
}
--
1.7.5.4
^ permalink raw reply related
* Re: frequent x crashes with gen6/sna
From: Daniel Vetter @ 2011-10-24 7:22 UTC (permalink / raw)
To: Dieter Mummenschanz; +Cc: intel-gfx, libva
In-Reply-To: <20111018184704.GA2914@phenom.ffwll.local>
On Tue, Oct 18, 2011 at 08:47:04PM +0200, Daniel Vetter wrote:
> On Tue, Oct 18, 2011 at 09:52:32AM +0200, Dieter Mummenschanz wrote:
> > In this special case the gpu was successfully reset and continued normally.
> >
> > Any other ideas?
>
> Not at the moment, unfortunately. Can you please report a bug against
> libva with a small summary of all the things we've already discussed here?
> Also please add a error_state with my patches applied. And don't forget to
> put me on cc and post the bug # here in this thread.
Any update on this? I've got other reports of libva related gpu hangs, but
you seem to be the only one who can grab the error_state ...
Yours, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [GIT PULL for v3.2] OMAP_VOUT: Few cleaups and feature addition
From: Laurent Pinchart @ 2011-10-24 7:22 UTC (permalink / raw)
To: hvaibhav; +Cc: linux-media, mchehab
In-Reply-To: <1319285184-14605-1-git-send-email-hvaibhav@ti.com>
Hi Vaibhav,
On Saturday 22 October 2011 14:06:24 hvaibhav@ti.com wrote:
> Hi Mauro,
>
> The following changes since commit
> 35a912455ff5640dc410e91279b03e04045265b2: Mauro Carvalho Chehab (1):
> Merge branch 'v4l_for_linus' into staging/for_v3.2
>
> are available in the git repository at:
>
> git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
> for-linux-media
>
> Archit Taneja (5):
> OMAP_VOUT: Fix check in reqbuf for buf_size allocation
> OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
> OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
> OMAP_VOUT: Add support for DSI panels
> OMAP_VOUT: Increase MAX_DISPLAYS to a larger value
What about http://patchwork.linuxtv.org/patch/299/ ? Do you plan to push it
through your tree, or should I push it through mine ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Vanilla-Kernel 3 - page allocation failure
From: Philipp Herz - Profihost AG @ 2011-10-24 7:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Rientjes, Andi Kleen, s.priebe, linux-kernel
In-Reply-To: <1319439819.2517.38.camel@edumazet-laptop>
Am 24.10.2011 09:03, schrieb Eric Dumazet:
> Le lundi 24 octobre 2011 à 08:33 +0200, Philipp Herz - Profihost AG a
> écrit :
>> Am 19.10.2011 03:58, schrieb David Rientjes:
>>> On Tue, 18 Oct 2011, Andi Kleen wrote:
>>>
>>>> Philipp Herz - Profihost AG<p.herz@profihost.ag> writes:
>>>>
>>>>> After updating kernel (x86_64) to stable version 3 there are a few
>>>>> messages appearing in the kernel log such as
>>>>>
>>>>> kworker/0:1: page allocation failure: order:1, mode:0x20
>>>>> mysql: page allocation failure: order:1, mode:0x20
>>>>> php5: page allocation failure: order:1, mode:0x20
>>>>
>>>> You just ran out of memory.
>>>>
>>>
>>> He ran out of order-1 physically contiguous memory and was unable to
>>> compact or reclaim because of the atomic context.
>>>
>>> Philipp, based on your pastes from another post, it's evident you're using
>>> CONFIG_SLAB and, unfortunately, it's not possible to change to single
>>> page allocations (which would only result in a page allocation failure if
>>> you were completely out of memory) without recompiling.
>>>
>>> You have a couple options:
>>>
>>> - recompile with BREAK_GFP_ORDER_HI redefined to 0 in mm/slab.c, or
>>>
>>> - recompile with CONFIG_SLUB instead of CONFIG_SLAB.
>>>
>>> It's very possible that neither of these will help, but it will tell you
>>> whether you need to go out and buy more RAM or not. If you try to
>>> recompile with BREAK_GFP_ORDER_HI, these may turn into order-0
>>> allocations. If you can't reboot, send the output of
>>> /proc/<pid>/net/protocols where<pid> is the pid of one of the above tasks
>>> (kworker, mysql, php5) when they are running and we'll know.
>>>
>>> [ Changing slab_break_gfp_order should really be a CONFIG_SLAB command-
>>> line option. It can't be runtime because slab depends on the order for
>>> caches remaining constant, but we can certainly change it on boot. ]
>>>
>>> If you try CONFIG_SLUB instead of CONFIG_SLAB, you can pass
>>> slub_max_order=0 on the command line and see if it helps.
>>
>> Hi David,
>>
>> we have recompiled the kernel of one machine with CONFIG_SLUB instead of
>> CONFIG_SLAB, but it is showing similar message.
>>
>> Now it's showing failure at "order:5, mode:0x4020".
>>
>> Call trace can be found at:
>> * http://pastebin.com/uGJiwvG1
>>
>> Comparing kernel 2.6.32 (mm/page_alloc.c) there seams to be the same way
>> of dealing with page allocation.
>>
>> Do you have an idea why these (warning) messages do never appear running
>> 2.6.32?
>
> Your tg3 has a firmware limitation, and some skbs using fragments have
> to be reallocated using a single and contiguous area of memory.
>
> Initial skb delivered by tcp stack only uses order-0 pages, but the
> reallocated one, being 64K, can be order-5
>
> You can avoid this by following tuning :
>
> ethtool -K eth0 sg off
>
ok,
does that mean that there was no firmware limitation with kernel 2.6.32
or that the tg3 module has any "disable warnings" flag matching
__GFP_NOWARN?
^ permalink raw reply
* [U-Boot] watchdog reset fails on kirkwood/dreamplug
From: Prafulla Wadaskar @ 2011-10-24 7:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111021142331.GI18283@titan.lakedaemon.net>
> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of Jason
> Sent: Friday, October 21, 2011 7:54 PM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] watchdog reset fails on kirkwood/dreamplug
>
> All,
>
> I have a bad problem. I'm using the watchdog that comes with the
> Marvell
> DreamPlug (kirkwood SoC). I'm using it because I occasionally get Linux
> kernel
> oops/freezes. The oops/freezes are not consistent. However, what is
> consistent, is that after a freeze, Linux fails to boot. It stops at
> 'Uncompressing Linux'.
>
> When I kill the process that kicks the dog, the reboot is initiated
> properly
> and the system comes back up just fine. It only fails when the system
> freezes.
>
> On warm reboots, is there something I should have u-boot reset that
> isn't? I'm
> a little out of my depth with this one and would appreciate any
> pointers.
Hi Jason
If you are using watch dog at kernel level, then you should reset it at u-boot level.
On warm start, I don't think watchdog registers gets changed by the system (I have not used them)
Regards..
Prafulla . .
>
> thx,
>
> Jason.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply
* Re: [PATCH V2 2/4] MIPS: Add board support for Loongson1B
From: Giuseppe CAVALLARO @ 2011-10-24 7:19 UTC (permalink / raw)
To: keguang.zhang
Cc: Wu Zhangjin, linux-mips, linux-kernel, ralf, r0bertz, netdev
In-Reply-To: <CAD+V5YKBkW52_md9rBeVZ1RXq2FGEXt=Ergsw+z8txMreZdNsA@mail.gmail.com>
On 10/21/2011 7:33 PM, Wu Zhangjin wrote:
> On Fri, Oct 21, 2011 at 6:28 PM, <keguang.zhang@gmail.com> wrote:
>> From: Kelvin Cheung <keguang.zhang@gmail.com>
>>
>> This patch adds basic platform support for Loongson1B
>> including serial port, ethernet, and interrupt handler.
>>
>> Loongson1B UART is compatible with NS16550A.
>> Loongson1B GMAC is built around Synopsys IP Core.
>>
>
> Perhaps you'd better split out the GMAC support to its own patch and
> send it to the net/ maintainer and the authors of the original files.
Also suggest you to provide the stmmac patches for net-next.
The stmmac driver has been recently updated and I've also several
patches to commit (for example for PCI etc) on it.
I'm happy that the support for big endianess arrived.
I supported a guy some time ago but he didn't provided me the patches
tested on his side :-(. So welcome yours and many thanks Kelvin!
Please send the stmmac patches and add me on CC. I'm happy to help you
on reviewing them.
>> diff --git a/drivers/net/stmmac/descs.h b/drivers/net/stmmac/descs.h
>> index 63a03e2..4db27d0 100644
>> --- a/drivers/net/stmmac/descs.h
>> +++ b/drivers/net/stmmac/descs.h
>> @@ -53,6 +53,38 @@ struct dma_desc {
>> u32 reserved3:5;
>> u32 disable_ic:1;
>> } rx;
>> +#ifdef CONFIG_MACH_LOONGSON1
>> + struct {
>> + /* RDES0 */
>> + u32 payload_csum_error:1;
>> + u32 crc_error:1;
>> + u32 dribbling:1;
>> + u32 error_gmii:1;
>> + u32 receive_watchdog:1;
>> + u32 frame_type:1;
>> + u32 late_collision:1;
>> + u32 ipc_csum_error:1;
>> + u32 last_descriptor:1;
>> + u32 first_descriptor:1;
>> + u32 vlan_tag:1;
>> + u32 overflow_error:1;
>> + u32 length_error:1;
>> + u32 sa_filter_fail:1;
>> + u32 descriptor_error:1;
>> + u32 error_summary:1;
>> + u32 frame_length:14;
>> + u32 da_filter_fail:1;
>> + u32 own:1;
>> + /* RDES1 */
>> + u32 buffer1_size:11;
>> + u32 buffer2_size:11;
>> + u32 reserved1:2;
>> + u32 second_address_chained:1;
>> + u32 end_ring:1;
>> + u32 reserved2:5;
>> + u32 disable_ic:1;
>> + } erx; /* -- enhanced -- */
>> +#else
>> struct {
>> /* RDES0 */
>> u32 payload_csum_error:1;
>> @@ -83,6 +115,7 @@ struct dma_desc {
>> u32 reserved2:2;
>> u32 disable_ic:1;
>> } erx; /* -- enhanced -- */
>> +#endif
>>
>> /* Transmit descriptor */
>> struct {
>> @@ -113,6 +146,40 @@ struct dma_desc {
>> u32 last_segment:1;
>> u32 interrupt:1;
>> } tx;
>> +#ifdef CONFIG_MACH_LOONGSON1
>> + struct {
>> + /* TDES0 */
>> + u32 deferred:1;
>> + u32 underflow_error:1;
>> + u32 excessive_deferral:1;
>> + u32 collision_count:4;
>> + u32 vlan_frame:1;
>> + u32 excessive_collisions:1;
>> + u32 late_collision:1;
>> + u32 no_carrier:1;
>> + u32 loss_carrier:1;
>> + u32 payload_error:1;
>> + u32 frame_flushed:1;
>> + u32 jabber_timeout:1;
>> + u32 error_summary:1;
>> + u32 ip_header_error:1;
>> + u32 time_stamp_status:1;
>> + u32 reserved1:13;
>> + u32 own:1;
>> + /* TDES1 */
>> + u32 buffer1_size:11;
>> + u32 buffer2_size:11;
>> + u32 time_stamp_enable:1;
>> + u32 disable_padding:1;
>> + u32 second_address_chained:1;
>> + u32 end_ring:1;
>> + u32 crc_disable:1;
>> + u32 checksum_insertion:2;
>> + u32 first_segment:1;
>> + u32 last_segment:1;
>> + u32 interrupt:1;
>> + } etx; /* -- enhanced -- */
>> +#else
>> struct {
>> /* TDES0 */
>> u32 deferred:1;
>> @@ -148,6 +215,7 @@ struct dma_desc {
>> u32 buffer2_size:13;
>> u32 reserved4:3;
>> } etx; /* -- enhanced -- */
>> +#endif
>> } des01;
>> unsigned int des2;
>> unsigned int des3;
>
>
> If the difference is very much, perhaps a new dma_desc struct can be
> defined instead.
>
Concerning the descriptors, we could have two different files:
descs_le.h
descs_be.h
and select their inclusion inside the common.h.
Please use instead of the macro CONFIG_MACH_LOONGSON1 another one more
generic e.g. CONFIG_STMMAC_BE (and add it in the driver's Kconfig).
On your platform you will have to enable it by default.
Or it could be the default on MIPS: LE will be on ARM and SuperH.
>> diff --git a/drivers/net/stmmac/enh_desc.c b/drivers/net/stmmac/enh_desc.c
>> index e5dfb6a..3b5e4f1 100644
>> --- a/drivers/net/stmmac/enh_desc.c
>> +++ b/drivers/net/stmmac/enh_desc.c
>> @@ -108,6 +108,7 @@ static int enh_desc_get_tx_len(struct dma_desc *p)
>> static int enh_desc_coe_rdes0(int ipc_err, int type, int payload_err)
>> {
>> int ret = good_frame;
>> +#ifndef CONFIG_MACH_LOONGSON1
>> u32 status = (type << 2 | ipc_err << 1 | payload_err) & 0x7;
>>
>> /* bits 5 7 0 | Frame status
>> @@ -145,6 +146,7 @@ static int enh_desc_coe_rdes0(int ipc_err, int type, int payload_err)
>> CHIP_DBG(KERN_ERR "RX Des0 status: No IPv4, IPv6 frame.\n");
>> ret = discard_frame;
>> }
>> +#endif
>> return ret;
>> }
>>
>> @@ -232,9 +234,17 @@ static void enh_desc_init_rx_desc(struct dma_desc *p, unsigned int ring_size,
>> int i;
>> for (i = 0; i < ring_size; i++) {
>> p->des01.erx.own = 1;
>> +#ifdef CONFIG_MACH_LOONGSON1
>> + p->des01.erx.buffer1_size = BUF_SIZE_2KiB - 1;
>> +#else
>> p->des01.erx.buffer1_size = BUF_SIZE_8KiB - 1;
>> +#endif
>> /* To support jumbo frames */
>> +#ifdef CONFIG_MACH_LOONGSON1
>> + p->des01.erx.buffer2_size = BUF_SIZE_2KiB - 1;
>> +#else
>> p->des01.erx.buffer2_size = BUF_SIZE_8KiB - 1;
>> +#endif
>> if (i == ring_size - 1)
>> p->des01.erx.end_ring = 1;
>> if (disable_rx_ic)
>> @@ -292,9 +302,15 @@ static void enh_desc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
>> int csum_flag)
>> {
>> p->des01.etx.first_segment = is_fs;
>> +#ifdef CONFIG_MACH_LOONGSON1
>> + if (unlikely(len > BUF_SIZE_2KiB)) {
>> + p->des01.etx.buffer1_size = BUF_SIZE_2KiB - 1;
>> + p->des01.etx.buffer2_size = len - BUF_SIZE_2KiB + 1;
>> +#else
>> if (unlikely(len > BUF_SIZE_4KiB)) {
>> p->des01.etx.buffer1_size = BUF_SIZE_4KiB;
>> p->des01.etx.buffer2_size = len - BUF_SIZE_4KiB;
>> +#endif
>> } else {
>> p->des01.etx.buffer1_size = len;
>> }
No. I do not want to see all these ifdef inside the code.
I had to rework some driver's part just last week to avoid this kind of
code. I suggest you to re-base the work against the net-next kernel and
look at how the ring/chained modes have been managed.
I added a new file called descs_com.h that you can re-use adding small
inline functions where define the changes for be mode.
> Is it possible to add two new macros RX_BUF_SIZE and TX_BUF_SIZE to .h
> instead? which may reduce code duplication.
This code exists because we have to properly handle the jumbo frames.
Note that this code has been reworked to use the ring/chained modes.
Take a look at descs_com.h.
I expect to see the driver on your platform that uses jumbo and
chained/ring modes.
Best Regards
Giuseppe
>
> Regards,
> Wu Zhangjin
>
>> --
>> 1.7.1
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [Bug 42090] [r300/compiler] [bisected] sauerbraten texture corruption
From: bugzilla-daemon @ 2011-10-24 7:19 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42090-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42090
--- Comment #2 from Fabio Pedretti <fabio.ped@libero.it> 2011-10-24 00:19:29 PDT ---
(In reply to comment #1)
> Created attachment 52640 [details] [review]
> Possible fix
>
> Does this patch fix the problem?
Yes (tested on current git and also with
0dc97e7fd49a5b8db25b95a1020fc598dba5cf65 reverted: both type of corruptions are
fixed with the patch).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [U-Boot] [PATCH v3 10/10] arm, davinci: add cam_enc_4xx support
From: Heiko Schocher @ 2011-10-24 7:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA482F3.90509@compulab.co.il>
Hello Igor,
Igor Grinberg wrote:
> On 10/21/2011 08:32 AM, Heiko Schocher wrote:
>> - DM368 SOC
>> - booting with spl not with UBL from TI
>> - before loading u-boot from NAND into RAM, test
>> the RAM with the post memory test. If error
>> is found, switch all LEDs on and halt system.
>> - SPI Flash
>> Dataflash Typ: M25PE80
>> - Ethernet DM9161BI
>> - MMC
>> - USB
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Cc: Sandeep Paulraj <s-paulraj@ti.com>
>> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
>> ---
[...]
>> diff --git a/board/ait/cam_enc_4xx/Makefile b/board/ait/cam_enc_4xx/Makefile
>> new file mode 100644
>> index 0000000..4804597
>> --- /dev/null
>> +++ b/board/ait/cam_enc_4xx/Makefile
[...]
> I don't think you should be adding this.
> Please, see the commit 464c79207c89f247f97b344495924eabb0c9738e
> (punt unused clean/distclean targets) by Mike.
Yep, you are right, done.
>> diff --git a/board/ait/cam_enc_4xx/cam_enc_4xx.c b/board/ait/cam_enc_4xx/cam_enc_4xx.c
>> new file mode 100644
>> index 0000000..059a08a
>> --- /dev/null
>> +++ b/board/ait/cam_enc_4xx/cam_enc_4xx.c
[...]
>> +int board_init(void)
>> +{
>> + gd->bd->bi_arch_number = MACH_TYPE_DAVINCI_DM365_EVM;
>
> You should be using the new standard for specifying the machine type.
> Please, read the README file (CONFIG_MACH_TYPE option).
Changed, thanks!
[...]
>> +static void davinci_std_write_page_syndrome(struct mtd_info *mtd,
>> + struct nand_chip *chip, const uint8_t *buf)
>> +{
>> + unsigned char davinci_ecc_buf[NAND_MAX_OOBSIZE];
>> + struct nand_chip *this = mtd->priv;
>> + int i, eccsize = chip->ecc.size;
>> + int eccbytes = chip->ecc.bytes;
>> + int eccsteps = chip->ecc.steps;
>> + int chunk = chip->ecc.bytes + chip->ecc.prepad + chip->ecc.postpad;
>> + int offset = 0;
>> + const uint8_t *p = buf;
>> + uint8_t *oob = chip->oob_poi;
>> +
>> + for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
>> + chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
>> + chip->write_buf(mtd, p, eccsize);
>> +
>> + /* Calculate ECC without prepad */
>> + chip->ecc.calculate(mtd, p, oob + chip->ecc.prepad);
>> +
>> + if (chip->ecc.prepad) {
>> + offset = ((chip->ecc.steps - eccsteps) * chunk);
>> + memcpy(&davinci_ecc_buf[offset], oob, chip->ecc.prepad);
>> + oob += chip->ecc.prepad;
>> + }
>> +
>> + offset = (((chip->ecc.steps - eccsteps) * chunk) +
>> + chip->ecc.prepad);
>
> 2 sets of parenthesis is enough.
> I don't see any good in having the whole expression wrapped.
Changed.
>> + memcpy(&davinci_ecc_buf[offset], oob, eccbytes);
>> + oob += eccbytes;
>> +
>> + if (chip->ecc.postpad) {
>> + offset = (((chip->ecc.steps - eccsteps) * chunk) +
>> + (chip->ecc.prepad + eccbytes));
>
> same here
Changed.
>> + memcpy(&davinci_ecc_buf[offset], oob,
>> + chip->ecc.postpad);
>> + oob += chip->ecc.postpad;
>> + }
>> + }
>> +
>> + /*
>> + * Write the sparebytes into the page once
>> + * all eccsteps have been covered
>> + */
>> + for (i = 0; i < mtd->oobsize; i++)
>> + writeb(davinci_ecc_buf[i], this->IO_ADDR_W);
>> +
>> + /* Calculate remaining oob bytes */
>> + i = mtd->oobsize - (oob - chip->oob_poi);
>
> This one looks good, I think the previous should be the same.
Yep.
[...]
>> +void enable_vbus(void)
>> +{
>> + /*
>> + * nothing to do, but this function is needed from
>> + * drivers/usb/musb/davinci.c
>> + */
>> +}
>
> I think the common way would be to define a "weak" implementation in
> drivers/usb/musb/davinci.c?
Yes, that would be cleaner, changed.
>> +
>> +int board_late_init(void)
>> +{
>> + struct davinci_gpio *gpio = davinci_gpio_bank45;
>> +
>> + /* 24MHz InputClock / 15 prediv -> 1.6 MHz timer running */
>> + while (get_timer_val() < 0x186a00)
>> + ;
>> +
>> + /* 1 sec reached -> stop timer, clear all LED */
>> + stop_timer();
>> + clrbits_le32(&gpio->out_data, CONFIG_CAM_ENC_LED_MASK);
>> + return 0;
>> +}
>> +
>> +void reset_phy(void)
>> +{
>> + char *name = "GENERIC @ 0x00";
>> +
>> + /* reset the phy */
>> + miiphy_reset(name, 0x0);
>> +}
>> +
>> +#else
>
> I think, adding a comment to which #if that #else belongs,
> will improve the understanding/readability.
Done.
[...]
Thanks for the review!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [U-Boot] [PATCH v3 8/8] km_arm: enable POST for these boards
From: Holger Brunck @ 2011-10-24 7:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111021221506.B1ED918AE81D@gemini.denx.de>
Hi Wolfgang,
On 10/22/2011 12:15 AM, Wolfgang Denk wrote:
> Dear Valentin Longchamp,
>
> In message <1314975550-15766-9-git-send-email-valentin.longchamp@keymile.com> you wrote:
>> The current km_arm boards have a Power-On test jumper. When this
>> jumper is set, this triggers some Power-On tests on the board.
>>
>> This patch enables the support of this jumper for starting the
>> memory_regions test when the jumper is set.
>>
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
>> Cc: Prafulla Wadaskar <prafulla@marvell.com>
>> ---
>> Changes for v2:
>> - adapted to CONFIG_POST_EXTERNAL_WORD_FUNCS
>> - implemented suggestion from Sergei
>> Changes for v3:
>> - moved arch_memory_test_prepare from post/board/km_arm to
>> board/keymile/km_arm/km_arm.c
>> ---
>> board/keymile/km_arm/km_arm.c | 32 ++++++++++++++++++++++++++++++++
>> include/configs/km/km_arm.h | 6 ++++++
>> 2 files changed, 38 insertions(+), 0 deletions(-)
>
> Applied, thanks.
>
you already committed a v4 of this patch together with the patch serie. See:
http://lists.denx.de/pipermail/u-boot/2011-October/104061.html
So could you please revert this one? Because this breaks the board support for
all our arm based boards.
Best regards
Holger
^ permalink raw reply
* Re: [PATCH ] i2c: omap: recover from Bus Busy condition
From: Rajeev kumar @ 2011-10-24 7:10 UTC (permalink / raw)
To: Shubhrajyoti D
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
Vikram Pandita
In-Reply-To: <1319439118-3800-1-git-send-email-shubhrajyoti@ti.com>
On 10/24/2011 12:21 PM, Shubhrajyoti D wrote:
> From: Vikram Pandita<vikram.pandita@ti.com>
>
> In case a peripheral is holding the DATA bus low, provide a 400Khz
> constant clock output using the TEST register.
>
> Also soft reset the I2C controller so that there is no stale state
> left in the HW state machine.
>
> A WARN_ON() will be generated when a BB timeout happens.
>
> Signed-off-by: Vikram Pandita<vikram.pandita@ti.com>
> Signed-off-by: Shubhrajyoti D<shubhrajyoti@ti.com>
> ---
> drivers/i2c/busses/i2c-omap.c | 15 +++++++++++++--
> 1 files changed, 13 insertions(+), 2 deletions(-)
Reviewed-by: Rajeev Kumar <rajeev-dlh.kumar@st.com>
~Rajeev
^ permalink raw reply
* Re: [PATCH ] i2c: omap: recover from Bus Busy condition
From: Rajeev kumar @ 2011-10-24 7:10 UTC (permalink / raw)
To: Shubhrajyoti D
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Vikram Pandita
In-Reply-To: <1319439118-3800-1-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
On 10/24/2011 12:21 PM, Shubhrajyoti D wrote:
> From: Vikram Pandita<vikram.pandita-l0cyMroinI0@public.gmane.org>
>
> In case a peripheral is holding the DATA bus low, provide a 400Khz
> constant clock output using the TEST register.
>
> Also soft reset the I2C controller so that there is no stale state
> left in the HW state machine.
>
> A WARN_ON() will be generated when a BB timeout happens.
>
> Signed-off-by: Vikram Pandita<vikram.pandita-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Shubhrajyoti D<shubhrajyoti-l0cyMroinI0@public.gmane.org>
> ---
> drivers/i2c/busses/i2c-omap.c | 15 +++++++++++++--
> 1 files changed, 13 insertions(+), 2 deletions(-)
Reviewed-by: Rajeev Kumar <rajeev-dlh.kumar-qxv4g6HH51o@public.gmane.org>
~Rajeev
^ permalink raw reply
* Re: [DVB] Digital Devices Cine CT V6 support
From: Oliver Endriss @ 2011-10-24 7:06 UTC (permalink / raw)
To: Sébastien RAILLARD; +Cc: Linux Media Mailing List
In-Reply-To: <004c01cc7a03$064111c0$12c33540$@coexsi.fr>
Hi,
> Using your latest development tree (hg clone
> http://linuxtv.org/hg/~endriss/media_build_experimental), I have made a
> small modification in ddbridge-core.c (see below) to make the new "Cine CT
> V6" card detected by the ddbridge module.
>
> With this small patch, the card is now detected, but not the double C/T
> tuner onboard.
This cannot work, as the cards requires different frontend drivers.
Please try a fresh check-out from
http://linuxtv.org/hg/~endriss/media_build_experimental
The Cine CT v6 is supported now.
> Also, I was wondering why they put a male and a female RF connectors on the
> "Cine CT V6" (maybe a loop-through?) where there are two female RF
> connectors on the "DuoFlex CT" card.
The second connector of the Cine CT is the loop-through output.
CU
Oliver
--
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qxl: reset update_surface
From: Gerd Hoffmann @ 2011-10-24 7:08 UTC (permalink / raw)
To: Alon Levy; +Cc: qemu-devel
In-Reply-To: <1319382232-23392-1-git-send-email-alevy@redhat.com>
On 10/23/11 17:03, Alon Levy wrote:
> update init_qxl_ram to reset update_surface to 0. This fixes one case
> of breakage when installing an old driver in a vm that had a new driver
> installed. The newer driver would know about surface creation and would
> change update_surface to !=0, then a reset would happen, all surfaces
> are destroyed, then the old driver is initialized and issues an
> UPDATE_AREA, and spice server aborts on invalid surface.
Patch added to spice patch queue.
thanks,
Gerd
^ 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.