* Re: XenVGAPassthroughTestedAdapters up to date?
From: hurenkam @ 2010-10-08 7:15 UTC (permalink / raw)
To: Jean Guyader; +Cc: Eric Stein, xen-devel
In-Reply-To: <AANLkTinTzJgh0VDgXWHLni+YpcGZu9ycs_9HOBJJrxFp@mail.gmail.com>
>> What patches did you apply? VGA passthru was first introduced in Xen 4.0,
>> it wasn't in Xen 3.4. Or has it been added recently?
>>
>> Also, what dom0 kernel did you use?
>> What grub settings (for device hiding etc)?
>>
>
> I use normal device pass throught, I forgot to mentioned that was
> passing it through as a secondary display adapter so no need to do any
> fancy VGA tweak for that.
>
> I used SLE 2.6.32 xen as dom0 + XCI patch queue.
> I used pci back directly to hide the device from dom0 after boot (echo
> the gpu BDF into sysfs).
>
> Jean
I have a similar experience using Xen 4.0.1, with linux pvops kernel
(2.6.32).
Somehow, i never seemed to get the 'Bios boot' to work, however, when
passing these cards through to the DomU, then the following
combinations
seem to work fine once started:
- Ubuntu Lucid (64bit) + Catalyst (10.7 or 10.8) (primary or
secondary)
- Windows XP (32bit) + Catalyst (10.7 or 10.8) (primary, have not
tried as secondary)
- Windows 7 (64bit) + Catalyst 10.9 (primary, have not
tried as secondary)
Note that when trying the opensource driver on ubuntu, it exits with
errors, which seem
to indicate it can't find the Bios.
I have a Asus P7P55D-Evo mainboard, with two Asus EAH4350 graphic
cards,
both cards are passed through to a domU, both don't show bios messages
on
boot (even when i use graphics passthru setting), but they work fine
with the installed drivers after the domains have booted.
For me, that's good enough ;-)
Regards,
Mark.
^ permalink raw reply
* [U-Boot] [PATCH] smc91111: add write_hwaddr
From: Thomas Chou @ 2010-10-08 7:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <m2d3rmjo0x.fsf@ohwell.denx.de>
On 10/07/2010 06:27 PM, Detlev Zundel wrote:
> Hi Wolfgang,
>
>> Dear Thomas Chou,
>>
>> In message<4CAC0B1E.1050007@wytron.com.tw> you wrote:
>>>
>>> I was confused by the greylisting of denx mail server and wondered why
>>> the first mail was not received after 12 hours.
>>
>> There is no greylisting on our side.
>
> Well actually we do run postgrey. But as yet we did not get any
> complaints that this interferes with regular usage. The default values
> of the software should not intrude much on completely unfiltered
> traffic.
Dear Wolfgang and Detlev,
The retransmission wait time on my first mail server is quite long and I
forgot that there is postgrey on denx mail server, so I sent the patch
again using another mail server. I wondered if my first mail server
changed IP. Sorry for the noise.
Best regards,
Thomas
^ permalink raw reply
* Re: [PATCH 05/18] fs: inode split IO and LRU lists
From: Christoph Hellwig @ 2010-10-08 7:14 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-6-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:19PM +1100, Dave Chinner wrote:
> From: Nick Piggin <npiggin@suse.de>
>
> The use of the same inode list structure (inode->i_list) for two
> different list constructs with different lifecycles and purposes
> makes it impossible to separate the locking of the different
> operations. Therefore, to enable the separation of the locking of
> the writeback and reclaim lists, split the inode->i_list into two
> separate lists dedicated to their specific tracking functions.
> @@ -410,7 +410,11 @@ writeback_single_inode(struct inode *inode, struct writeback_control *wbc)
> redirty_tail(inode);
> } else {
> /* The inode is clean */
> - list_move(&inode->i_list, &inode_unused);
> + list_del_init(&inode->i_io);
> + if (list_empty(&inode->i_lru)) {
> + list_add(&inode->i_lru, &inode_unused);
> + percpu_counter_inc(&nr_inodes_unused);
> + }
This looks like it belongs into the earlier patch. Also instead of
making nr_inodes_unused non-static a helper to manipulate it might
be a better idea.
^ permalink raw reply
* RE: [PATCH v1 11/16] OMAP3: hwmod DSS: RFBI Move init,exit to driver
From: Guruswamy, Senthilvadivu @ 2010-10-08 7:13 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: khilman@deeprootsystems.com, tomi.valkeinen@nokia.com,
paul@pwsan.com, Hiremath, Vaibhav, linux-omap@vger.kernel.org
In-Reply-To: <20101007214722.16799b9a@surf>
> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> Sent: Friday, October 08, 2010 1:17 AM
> To: Guruswamy, Senthilvadivu
> Cc: khilman@deeprootsystems.com; tomi.valkeinen@nokia.com; paul@pwsan.com;
> Hiremath, Vaibhav; linux-omap@vger.kernel.org
> Subject: Re: [PATCH v1 11/16] OMAP3: hwmod DSS: RFBI Move init,exit to
> driver
>
> Hello Senthil,
>
> On Wed, 6 Oct 2010 16:44:54 +0530
> Guruswamy Senthilvadivu <svadivu@ti.com> wrote:
>
> > diff --git a/drivers/video/omap2/dss/rfbi.c
> b/drivers/video/omap2/dss/rfbi.c
> > index 23598ea..9bee39d 100644
> > --- a/drivers/video/omap2/dss/rfbi.c
> > +++ b/drivers/video/omap2/dss/rfbi.c
> > @@ -100,6 +100,7 @@ static int rfbi_convert_timings(struct rfbi_timings
> *t);
> > static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
> >
> > static struct {
> > + struct platform_device *pdev;
> > void __iomem *base;
> >
> > unsigned long l4_khz;
> > @@ -142,11 +143,22 @@ static inline u32 rfbi_read_reg(const struct
> rfbi_reg idx)
> > /* RFBI HW IP initialisation */
> > static int omap_rfbihw_probe(struct platform_device *pdev)
> > {
> > - return 0;
> > + int r;
> > + rfbi.pdev = pdev;
> > +
> > + r = rfbi_init();
> > + if (r) {
> > + DSSERR("Failed to initialize rfbi\n");
> > + goto err_rfbi;
> > + }
> > +
> > +err_rfbi:
> > + return r;
> > }
> >
> > static int omap_rfbihw_remove(struct platform_device *pdev)
> > {
> > + rfbi_exit();
> > return 0;
> > }
> >
>
> Instead of having probe() and remove() functions that call the existing
> init() and exit(), why not making your driver look like most Linux
> drivers here, and directly do the initialization in probe() and the
> cleanup in remove() ?
>
[Senthil] When I do existing code movement I don't change it one single patch just to make the review concentrate on the place of movement.
I could submit additional patches to remove the extra function calls wherever required.
> Concerning the added pdev field to the rfbi structure, do you really it
> at this point ?
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* + fs-fs-writebackc-restore-lost-comment.patch added to -mm tree
From: akpm @ 2010-10-08 7:13 UTC (permalink / raw)
To: mm-commits; +Cc: akpm, axboe
The patch titled
fs/fs-writeback.c: restore lost comment
has been added to the -mm tree. Its filename is
fs-fs-writebackc-restore-lost-comment.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: fs/fs-writeback.c: restore lost comment
From: Andrew Morton <akpm@linux-foundation.org>
I had to go back to a 2.6.20 tree to work out why we're adding a
number-of-inodes into a number-of-pages count. Restore the lost comment.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/fs-writeback.c | 4 ++++
1 file changed, 4 insertions(+)
diff -puN fs/fs-writeback.c~fs-fs-writebackc-restore-lost-comment fs/fs-writeback.c
--- a/fs/fs-writeback.c~fs-fs-writebackc-restore-lost-comment
+++ a/fs/fs-writeback.c
@@ -721,6 +721,10 @@ static long wb_check_old_data_flush(stru
return 0;
wb->last_old_flush = jiffies;
+ /*
+ * Add in the number of potentially dirty inodes, because each inode
+ * write can dirty pagecache in the underlying blockdev.
+ */
nr_pages = global_page_state(NR_FILE_DIRTY) +
global_page_state(NR_UNSTABLE_NFS) +
(inodes_stat.nr_inodes - inodes_stat.nr_unused);
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
maintainers-haavard-has-moved.patch
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
arch-mips-include-asm-fcntlh-needs-typesh.patch
arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch
arch-x86-kernel-entry_32s-i386-too.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
drivers-media-video-cx23885-cx23885-corec-fix-cx23885_dev_checkrevision.patch
fs-notify-fanotify-fanotify_userc-fix-warnings.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-low-threshold-to-pwm-backlight.patch
serial8250-ratelimit-too-much-work-error-fix.patch
serial8250-ratelimit-too-much-work-error-fix-fix.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
drivers-message-fusion-mptsasc-fix-warning.patch
vfs-allow-mnt_want_write-to-sleep-fix.patch
mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-fix.patch
rmap-make-anon_vma_free-static-fix.patch
vmstat-include-compactionh-when-config_compaction-fix.patch
fs-fs-writebackc-restore-lost-comment.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
hpet-factor-timer-allocate-from-open-fix.patch
m68k-__pa-cast-arg-to-long.patch
kernelh-add-minmax3-macros-fix.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
printk-declare-printk_ratelimit_state-in-ratelimith-fix.patch
vsprintfc-use-default-pointer-field-size-for-null-strings-fix.patch
scripts-get_maintainerpl-add-git-blame-rolestats-authored-lines-information.patch
idr-fix-idr_pre_get-locking-description-fix.patch
checkpatch-returning-errno-typically-should-be-negative.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
vcs-add-poll-fasync-support-fix-fix.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatch-fixes.patch
drivers-char-hvc_consolec-remove-unneeded-__set_current_statetask_running.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
fuse-use-release_pages.patch
pps-add-async-pps-event-handler-fix.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-fix.patch
kernel-resourcec-handle-reinsertion-of-an-already-inserted-resource.patch
ramoops-use-the-platform-data-structure-instead-of-module-params-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
getblk-handle-2tb-devices.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* Re: [PULL] soc-camera: welcome a new host: OMAP1 and a couple of new sensor drivers
From: Laurent Pinchart @ 2010-10-08 7:12 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Linux Media Mailing List, Mauro Carvalho Chehab
In-Reply-To: <Pine.LNX.4.64.1010080848550.21992@axis700.grange>
Hi Guennadi,
On Friday 08 October 2010 09:00:36 Guennadi Liakhovetski wrote:
> Hi Mauro
>
> So, as promised, here goes part 2 of 2.6.37 patches for soc-camera and
> related. There's also going to be one issue with this one to take care of:
> the last patch will conflict with Laurent's pad-level ops patches, which
> also move mediabus pixel codes around. But since Laurent's patches are
> still at the RFC stage, AFAICS, they'll have to be extended slightly:)
That's fine with me.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Configuration of nestedhvm
From: Keir Fraser @ 2010-10-08 7:12 UTC (permalink / raw)
To: Dong, Eddie; +Cc: Xen-devel
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22DBEA36C@shsmsx501.ccr.corp.intel.com>
On 08/10/2010 05:34, "Dong, Eddie" <eddie.dong@intel.com> wrote:
> Nested virtualization usage model is emerging, however we must guarantee it
> won't impact the performance of simple virtualization.
> This patch add an boot parameter for nested virtualization, which is disabled
> by default for now.
What's the point when a per-domain config option is going to be implemented?
You can then simply not configure nestedhvm for a domain you want to test
without that capability? I suppose it makes your second patch make a bit
more sense than it would in total isolation.
I think patch#2 probably makes sense, but it should wait for the patch that
actually implements the per-domain config option, and properly implements
is_nestedhvm(), before going in.
-- Keir
^ permalink raw reply
* RE: [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP
From: Guruswamy, Senthilvadivu @ 2010-10-08 7:11 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: khilman@deeprootsystems.com, tomi.valkeinen@nokia.com,
paul@pwsan.com, Hiremath, Vaibhav, linux-omap@vger.kernel.org
In-Reply-To: <20101007214957.79ca0a9b@surf>
> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> Sent: Friday, October 08, 2010 1:20 AM
> To: Guruswamy, Senthilvadivu
> Cc: khilman@deeprootsystems.com; tomi.valkeinen@nokia.com; paul@pwsan.com;
> Hiremath, Vaibhav; linux-omap@vger.kernel.org
> Subject: Re: [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for
> each DSS HW IP
>
> Hello Senthil,
>
> I forgot one comment: in most Linux drivers, it is customary to put the
> platform_driver definition just above the driver initialization
> function, both of them at the end of the file. Of course, it's nothing
> mandatory, but most of the drivers are organized this way, making it
> easy for developers to find their way in all drivers.
>
> So, in other words, this:
>
[Senthil] I put it above as part of all the static methods and structures.
Will look at the other omap drivers before I change.
> > +/* DISPC HW IP initialisation */
> > +static int omap_dispchw_probe(struct platform_device *pdev)
> > +{
> > + return 0;
> > +}
> > +
> > +static int omap_dispchw_remove(struct platform_device *pdev)
> > +{
> > + return 0;
> > +}
> > +
> > +static struct platform_driver omap_dispchw_driver = {
> > + .probe = omap_dispchw_probe,
> > + .remove = omap_dispchw_remove,
> > + .driver = {
> > + .name = "dss_dispc",
> > + .owner = THIS_MODULE,
> > + },
> > +};
>
> Should be just above this:
>
> > +static int __init omap_dispc_init(void)
> > +{
> > + return platform_driver_register(&omap_dispchw_driver);
> > +}
> > +
> > +device_initcall(omap_dispc_init);
>
> Regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* [Bug 30693] [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
From: bugzilla-daemon @ 2010-10-08 7:10 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30693-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30693
--- Comment #3 from darkbasic <darkbasic4@gmail.com> 2010-10-08 00:10:45 PDT ---
As I said latest snapshot, so mesa 7.10-devel.
The screenshot shows what I see instead of the blur effect: the window becomes
dark gray.
--
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
* RE: [PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit to driver
From: Guruswamy, Senthilvadivu @ 2010-10-08 7:09 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: khilman@deeprootsystems.com, tomi.valkeinen@nokia.com,
paul@pwsan.com, Hiremath, Vaibhav, linux-omap@vger.kernel.org
In-Reply-To: <20101007215733.5ab1c091@surf>
> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> Sent: Friday, October 08, 2010 1:28 AM
> To: Guruswamy, Senthilvadivu
> Cc: khilman@deeprootsystems.com; tomi.valkeinen@nokia.com; paul@pwsan.com;
> Hiremath, Vaibhav; linux-omap@vger.kernel.org
> Subject: Re: [PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit to
> driver
>
> Hello Senthil,
>
> On Wed, 6 Oct 2010 16:44:56 +0530
> Guruswamy Senthilvadivu <svadivu@ti.com> wrote:
>
> > diff --git a/drivers/video/omap2/dss/venc.c
> b/drivers/video/omap2/dss/venc.c
> > index ec17b28..3a121cb 100644
> > --- a/drivers/video/omap2/dss/venc.c
> > +++ b/drivers/video/omap2/dss/venc.c
> > @@ -87,26 +87,6 @@
> > #define VENC_OUTPUT_TEST 0xC8
> > #define VENC_DAC_B__DAC_C 0xC8
> >
> > -/* VENC HW IP initialisation */
> > -static int omap_venchw_probe(struct platform_device *pdev)
> > -{
> > - return 0;
> > -}
> > -
> > -static int omap_venchw_remove(struct platform_device *pdev)
> > -{
> > - return 0;
> > -}
> > -
> > -static struct platform_driver omap_venchw_driver = {
> > - .probe = omap_venchw_probe,
> > - .remove = omap_venchw_remove,
> > - .driver = {
> > - .name = "dss_venc",
> > - .owner = THIS_MODULE,
> > - },
> > -};
>
> Would be better in patch 7/16 to put this stuff at the correct place
> (bottom of the file) so it does not need to be moved here.
>
[Senthil] Taken. Will do the movement in the first patch itself.
> > +/* VENC HW IP initialisation */
> > +static int omap_venchw_probe(struct platform_device *pdev)
> > +{
> > + int r;
> > + venc.pdev = pdev;
> > +
> > + r = venc_init(pdev);
> > + if (r) {
> > + DSSERR("Failed to initialize venc\n");
> > + goto err_venc;
> > + }
> > +
> > +err_venc:
> > + return r;
> > +}
> > +
> > +static int omap_venchw_remove(struct platform_device *pdev)
> > +{
> > + venc_exit();
> > + return 0;
> > +}
>
> Same comment as before: include the code of venc_init() and venc_exit()
> directly in the ->probe() and ->remove() hooks respectively.
>
> > +struct regulator *dss_get_vdda_dac(void)
> > +{
> > + struct regulator *reg;
> > +
> > + if (venc.vdda_dac_reg != NULL)
> > + return venc.vdda_dac_reg;
> > +
> > + reg = regulator_get(&venc.pdev->dev, "vdda_dac");
> > + if (!IS_ERR(reg))
> > + venc.vdda_dac_reg = reg;
> >
> > + return reg;
> > +}
>
> As far as I can see, this function is now only used in venc_init(),
> which is in the same file, so the function should be static, and the
> prototype removed from drivers/video/omap2/dss/core.h.
>
> I'm also a bit skeptical about what this function does. It is called
> this way in venc_init():
>
> venc.vdda_dac_reg = dss_get_vdda_dac();
>
> so it is dss_get_vdda_dac() responsability to set venc.vdda_dac_reg, or
> is it the caller responsability ?
>
> Moreover, the logic in dss_get_vdda_dac() that tests whether
> venc.vdda_dac_reg is already initialized seems to indicate that this
> function could be called several times. However, I only see it called
> from venc_init(), which as far as I understand is called only once.
>
[Senthil] when code was in core.c there were chances of it getting called more than once. Now it is called only once as you see, so it could be made static.
> Isn't it possible to simplify this by removing the dss_get_vdda_dac()
> function and just doing:
>
> venc.vdda_dac_reg = regulator_get(&venc.pdev->dev, "vdda_dac");
>
> in the venc_init() function (which should become the ->probe() method).
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* [PATCH 00/08] ARM: Dynamic IRQ demux support
From: Eric Miao @ 2010-10-08 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimAjypE8jTEymyO-0FucXrT8voQ7jVxiZxHF==d@mail.gmail.com>
On Thu, Oct 7, 2010 at 2:39 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> Hi Eric,
>
> On Wed, Oct 6, 2010 at 10:06 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Wed, Oct 6, 2010 at 3:17 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> ARM: Dynamic IRQ demux support
>
>> Just FYI, I had a patch months ago for this:
>>
>> http://www.spinics.net/linux/lists/arm-kernel/msg92836.html
>>
>> Do you think that's a simpler way to go?
>
> Thanks for the pointer. I wasn't aware of your patch, but the fact
> that both of us came up with similar solutions to the same problem
> clearly shows that there is a need for this feature.
>
> Your patch is much less intrusive compared to what i came up with. I
> like the simplicity. I guess it is natural that the simplicity comes
> with a bit of overhead. I'm thinking of the extra branches and
> whatever potential cache misses coming from the code and callback
> being located in different cache lines compared to the rest of the
> code in __irq_svc and __irq_usr.
>
> My patches keeps the handlers in the same cache lines as before, but
> this comes with the cost of more serious rearrangement of the code.
> Also, my alignment_trap patch may decrease performance, not sure how
> to deal with that in a good way.
Yeah, I was thinking of the performance degradation at that time as well.
What worried me most is actually the long jump. However, we do have
a long jump to asm_do_IRQ anyway.
And the optimizations like get_irqnr_preamble and get_irqnr_and_base
can be carried out in C code as well, or if that's tricky enough, inline
assembly code can also help.
>
> I don't mind so much which patch that gets merged, but I'm a little
> bit concerned about code duplication. My patch moves macros into a
> header file that each demux instance can make use of to minimize the
> amount of duplicated code. I'm not sure how you are planning on
> implementing each demux instance. If possible I'd like to see the
> irq_handler macro in a header file somewhere so we don't have to
> duplicate that code.
Machines will have to specify their IRQ demux handler, which could be
same among a group of machines which share common demux code, and
thus duplication can be avoided.
>
> On top of that I'd also like to break out the GIC demux code and put
> it in a central location, but that's a separate issue.
I think we can make a common function call for all the IRQ demux handler
for GIC then.
>
> Any thoughts? Shall I try to move the irq_handler macro to some header file?
>
Your patch is excellent, I don't mind either which gets in. What I'm a
bit concerned is the effort to keep up with the mostly optimized code.
I was thinking of a bit (not that much significant I guess) performance loss
when multiple IRQ demux handler is required for the sake of simplicity
and less intrusiveness, while still able to use the original optimized path
when that's not required (i.e. turning CONFIG_.... off).
Thoughts?
> Thanks,
>
> / magnus
>
^ permalink raw reply
* Re: [PATCH 00/08] ARM: Dynamic IRQ demux support
From: Eric Miao @ 2010-10-08 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimAjypE8jTEymyO-0FucXrT8voQ7jVxiZxHF==d@mail.gmail.com>
On Thu, Oct 7, 2010 at 2:39 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> Hi Eric,
>
> On Wed, Oct 6, 2010 at 10:06 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Wed, Oct 6, 2010 at 3:17 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> ARM: Dynamic IRQ demux support
>
>> Just FYI, I had a patch months ago for this:
>>
>> http://www.spinics.net/linux/lists/arm-kernel/msg92836.html
>>
>> Do you think that's a simpler way to go?
>
> Thanks for the pointer. I wasn't aware of your patch, but the fact
> that both of us came up with similar solutions to the same problem
> clearly shows that there is a need for this feature.
>
> Your patch is much less intrusive compared to what i came up with. I
> like the simplicity. I guess it is natural that the simplicity comes
> with a bit of overhead. I'm thinking of the extra branches and
> whatever potential cache misses coming from the code and callback
> being located in different cache lines compared to the rest of the
> code in __irq_svc and __irq_usr.
>
> My patches keeps the handlers in the same cache lines as before, but
> this comes with the cost of more serious rearrangement of the code.
> Also, my alignment_trap patch may decrease performance, not sure how
> to deal with that in a good way.
Yeah, I was thinking of the performance degradation at that time as well.
What worried me most is actually the long jump. However, we do have
a long jump to asm_do_IRQ anyway.
And the optimizations like get_irqnr_preamble and get_irqnr_and_base
can be carried out in C code as well, or if that's tricky enough, inline
assembly code can also help.
>
> I don't mind so much which patch that gets merged, but I'm a little
> bit concerned about code duplication. My patch moves macros into a
> header file that each demux instance can make use of to minimize the
> amount of duplicated code. I'm not sure how you are planning on
> implementing each demux instance. If possible I'd like to see the
> irq_handler macro in a header file somewhere so we don't have to
> duplicate that code.
Machines will have to specify their IRQ demux handler, which could be
same among a group of machines which share common demux code, and
thus duplication can be avoided.
>
> On top of that I'd also like to break out the GIC demux code and put
> it in a central location, but that's a separate issue.
I think we can make a common function call for all the IRQ demux handler
for GIC then.
>
> Any thoughts? Shall I try to move the irq_handler macro to some header file?
>
Your patch is excellent, I don't mind either which gets in. What I'm a
bit concerned is the effort to keep up with the mostly optimized code.
I was thinking of a bit (not that much significant I guess) performance loss
when multiple IRQ demux handler is required for the sake of simplicity
and less intrusiveness, while still able to use the original optimized path
when that's not required (i.e. turning CONFIG_.... off).
Thoughts?
> Thanks,
>
> / magnus
>
^ permalink raw reply
* Re: [PATCH 04/18] fs: Implement lazy LRU updates for inodes.
From: Christoph Hellwig @ 2010-10-08 7:08 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-5-git-send-email-david@fromorbit.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
A few nipicks on the comments or lack thereof below:
> @@ -489,8 +484,15 @@ static void prune_icache(int nr_to_scan)
>
> inode = list_entry(inode_unused.prev, struct inode, i_list);
>
> - if (inode->i_state || atomic_read(&inode->i_count)) {
> + if (atomic_read(&inode->i_count) ||
> + (inode->i_state & ~I_REFERENCED)) {
> + list_del_init(&inode->i_list);
> + percpu_counter_dec(&nr_inodes_unused);
> + continue;
> + }
> + if (inode->i_state & I_REFERENCED) {
> list_move(&inode->i_list, &inode_unused);
> + inode->i_state &= ~I_REFERENCED;
> continue;
I think this code could use some comments explaining the lazy LRU
scheme.
> - if (inode != list_entry(inode_unused.next,
> - struct inode, i_list))
> - continue; /* wrong inode or list_empty */
> - if (!can_unuse(inode))
> + /*
> + * if we can't reclaim this inod immediately, give it
> + * another pass through the free list so we don't spin
> + * on it.
s/inod/inode/
> +
> + /*
> + * We avoid moving dirty inodes back onto the LRU now because I_FREEING
> + * is set and hence writeback_single_inode() won't move the inode
> + * around.
> + */
> + if (!list_empty(&inode->i_list)) {
> + list_del_init(&inode->i_list);
> + percpu_counter_dec(&nr_inodes_unused);
> + }
> +
The comment is a bit misleading. We do not only avoid moving it to the
LRU, but actively delete the inode from the LRU here. I don't think the
I_FREEING check isn't the only reason - the LRU code traditionally
couldn't deal with unlinked inodes at all, although the switch to
->evict_inode probably has fixed that.
^ permalink raw reply
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Jonathan Nieder @ 2010-10-08 7:05 UTC (permalink / raw)
To: Johannes Sixt
Cc: Sverre Rabbelier, David Barr, Git Mailing List,
Ramkumar Ramachandra
In-Reply-To: <4CAEBF2E.8020206@viscovery.net>
Johannes Sixt wrote:
> Am 10/7/2010 22:28, schrieb Jonathan Nieder:
>> | For a command (like filter-branch --subdirectory-filter) that wants
>> | to commit a lot of trees that already exist in the object db, writing
>> | undeltified objects as loose files only to repack them later can
>> | involve a significant amount[*] of overhead.
>
> 1. But when an object already exists in the db, it won't be written again,
> will it?
In David's application, the trees already exist, but the commits are new.
> 2. Even though fast-import puts all (new) objects into a pack file, the
> pack is heavily sub-optimal, and you should repack -f anyway. So what's
> the point? Only to avoid a loose object?
To avoid thousands of loose objects.
> (I'm not saying that the patch is unwanted, but only that the
> justification is still not sufficiently complete.)
No problem - these questions are useful. If the result is learning
that something else is responsible for the speedup David observed in
his script, that would not be a bad outcome after all.
I suppose supporting M 040000 <tree> "" and C <path> "" could still
be a good idea in that case anyway, for the convenience of front-end
authors.
Jonathan
who still hasn't reviewed the patch (sorry)
^ permalink raw reply
* Re: [lm-sensors] [PATCH] coretemp: fix reading of microcode revision
From: Jan Beulich @ 2010-10-08 7:05 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4CADB0A1020000780001B335@vpn.id2.novell.com>
>>> On 07.10.10 at 20:46, Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Oct 07, 2010 at 02:36:01AM -0700, Jan Beulich wrote:
>> @@ -327,8 +336,13 @@ static int __devinit coretemp_probe(stru
>>
>> if ((c->x86_model = 0xe) && (c->x86_mask < 0xc)) {
>> /* check for microcode update */
>> - rdmsr_on_cpu(data->id, MSR_IA32_UCODE_REV, &eax, &edx);
>> - if (edx < 0x39) {
>> + err = smp_call_function_single(data->id, get_ucode_rev_on_cpu,
>> + &edx, 1);
>> + if (err)
>> + dev_warn(&pdev->dev,
>> + "Cannot determine microcode revision "
>> + "of the CPU!\n");
>
> When err, need to call dev_err and go to exit_free. This error handling
> should
> be same as edx < 0x39 case.
Hmm, not sure - I'd prefer to consider the machine usable in this
(theoretical only anyway) case.
Jan
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [patch] gdth: integer overflow in ioctl
From: Dan Carpenter @ 2010-10-08 7:03 UTC (permalink / raw)
To: Achim Leubner
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, kernel-janitors
gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.
We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer. Then when we do the
copy_from_user(), it would result in a memory corruption.
CC: stable@kernel.org
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b860d65..4cf7ffa 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -4175,6 +4175,14 @@ static int ioc_general(void __user *arg, char *cmnd)
ha = gdth_find_ha(gen.ionode);
if (!ha)
return -EFAULT;
+
+ if (gen.data_len > INT_MAX)
+ return -EINVAL;
+ if (gen.sense_len > INT_MAX)
+ return -EINVAL;
+ if (gen.data_len + gen.sense_len > INT_MAX)
+ return -EINVAL;
+
if (gen.data_len + gen.sense_len != 0) {
if (!(buf = gdth_ioctl_alloc(ha, gen.data_len + gen.sense_len,
FALSE, &paddr)))
^ permalink raw reply related
* [patch] gdth: integer overflow in ioctl
From: Dan Carpenter @ 2010-10-08 7:03 UTC (permalink / raw)
To: Achim Leubner
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, kernel-janitors
gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.
We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer. Then when we do the
copy_from_user(), it would result in a memory corruption.
CC: stable@kernel.org
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b860d65..4cf7ffa 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -4175,6 +4175,14 @@ static int ioc_general(void __user *arg, char *cmnd)
ha = gdth_find_ha(gen.ionode);
if (!ha)
return -EFAULT;
+
+ if (gen.data_len > INT_MAX)
+ return -EINVAL;
+ if (gen.sense_len > INT_MAX)
+ return -EINVAL;
+ if (gen.data_len + gen.sense_len > INT_MAX)
+ return -EINVAL;
+
if (gen.data_len + gen.sense_len != 0) {
if (!(buf = gdth_ioctl_alloc(ha, gen.data_len + gen.sense_len,
FALSE, &paddr)))
^ permalink raw reply related
* [PATCH 2/2] MMCI: add SDIO support for ST Variants
From: Linus Walleij @ 2010-10-08 7:02 UTC (permalink / raw)
To: linux-arm-kernel
This adds some minor variant data and trickery to enable SDIO
on the ST Micro variants of MMCI/PL180.
Signed-off-by: Marcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
drivers/mmc/host/mmci.c | 36 +++++++++++++++++++++++++++++++++++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 09bcce7..cd9414b 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -19,6 +19,7 @@
#include <linux/highmem.h>
#include <linux/log2.h>
#include <linux/mmc/host.h>
+#include <linux/mmc/card.h>
#include <linux/amba/bus.h>
#include <linux/clk.h>
#include <linux/scatterlist.h>
@@ -54,6 +55,7 @@ struct variant_data {
unsigned int fifosize;
unsigned int fifohalfsize;
bool singleirq;
+ bool sdio;
};
static struct variant_data variant_arm = {
@@ -67,6 +69,7 @@ static struct variant_data variant_u300 = {
.fifohalfsize = 8 * 4,
.clkreg_enable = 1 << 13, /* HWFCEN */
.datalength_bits = 16,
+ .sdio = true,
};
static struct variant_data variant_ux500 = {
@@ -76,6 +79,7 @@ static struct variant_data variant_ux500 = {
.clkreg_enable = 1 << 14, /* HWFCEN */
.datalength_bits = 24,
.singleirq = true,
+ .sdio = true,
};
/*
@@ -217,6 +221,11 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
irqmask = MCI_TXFIFOHALFEMPTYMASK;
}
+ /* The ST Micro variants has a special bit to enable SDIO */
+ if (variant->sdio && host->mmc->card)
+ if (mmc_card_sdio(host->mmc->card))
+ datactrl |= MCI_ST_DPSM_SDIOEN;
+
writel(datactrl, base + MMCIDATACTRL);
writel(readl(base + MMCIMASK0) & ~MCI_DATAENDMASK, base + MMCIMASK0);
mmci_set_mask1(host, irqmask);
@@ -415,7 +424,32 @@ static int mmci_pio_write(struct mmci_host *host, char *buffer, unsigned int rem
variant->fifosize : variant->fifohalfsize;
count = min(remain, maxcnt);
- writesl(base + MMCIFIFO, ptr, count >> 2);
+ /*
+ * The ST Micro variant for SDIO transfer sizes
+ * less then 8 bytes should have clock H/W flow
+ * control disabled.
+ */
+ if (variant->sdio &&
+ mmc_card_sdio(host->mmc->card)) {
+ if (count < 8)
+ writel(readl(host->base + MMCICLOCK) &
+ ~variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ else
+ writel(readl(host->base + MMCICLOCK) |
+ variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ }
+
+ /*
+ * SDIO especially may want to send something that is
+ * not divisible by 4 (as opposed to card sectors
+ * etc), and the FIFO only accept full 32-bit writes.
+ * So compensate by adding +3 on the count, a single
+ * byte become a 32bit write, 7 bytes will be two
+ * 32bit writes etc.
+ */
+ writesl(base + MMCIFIFO, ptr, (count + 3) >> 2);
ptr += count;
remain -= count;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mmc: MMC 4.4 DDR support
From: Adrian Hunter @ 2010-10-08 7:02 UTC (permalink / raw)
To: Philip Rakity; +Cc: linux-mmc@vger.kernel.org
In-Reply-To: <DFA7B5FE-718A-484B-BA1D-D1B44E3A5A32@marvell.com>
On 01/10/10 06:01, ext Philip Rakity wrote:
>
> I was wondering if we could remove one of the CAPS for DDR voltage (MMC_CAP_1_8V_DDR and MMC_CAP_1_2V_DDR). Both 1.2 and 1.8v are defined in the JEDEC Standard No. 84-A441.
>
> The sd 3.0 host controller only defines the option for 1.8v. I cannot see a way to set 1.2v.
>
> If this makes sense I can prepare a patch.--
If the host controller does not support 1.2V DDR then it should definitely
not set MMC_CAP_1_2V_DDR. That is precisely what the caps are for.
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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
* [PATCH 1/2] MMCI: add some register defines for ST Micro variants
From: Linus Walleij @ 2010-10-08 7:02 UTC (permalink / raw)
To: linux-arm-kernel
This adds a few registers to the MMCI/PL180 derivates that
is used for some odd control stuff like SDIO.
Signed-off-by: Marcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
drivers/mmc/host/mmci.h | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index acac081..690f2c6 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -54,10 +54,16 @@
#define MCI_DPSM_MODE (1 << 2)
#define MCI_DPSM_DMAENABLE (1 << 3)
#define MCI_DPSM_BLOCKSIZE (1 << 4)
-#define MCI_DPSM_RWSTART (1 << 8)
-#define MCI_DPSM_RWSTOP (1 << 9)
-#define MCI_DPSM_RWMOD (1 << 10)
-#define MCI_DPSM_SDIOEN (1 << 11)
+/* Control register extensions in the ST Micro U300 and Ux500 versions */
+#define MCI_ST_DPSM_RWSTART (1 << 8)
+#define MCI_ST_DPSM_RWSTOP (1 << 9)
+#define MCI_ST_DPSM_RWMOD (1 << 10)
+#define MCI_ST_DPSM_SDIOEN (1 << 11)
+/* Control register exeensions in the ST Micro Ux500 versions */
+#define MCI_ST_DPSM_DMAREQCTL (1 << 12)
+#define MCI_ST_DPSM_DBOOTMODEEN (1 << 13)
+#define MCI_ST_DPSM_BUSYMODE (1 << 14)
+#define MCI_ST_DPSM_DDRMODE (1 << 15)
#define MMCIDATACNT 0x030
#define MMCISTATUS 0x034
--
1.6.3.3
^ permalink raw reply related
* Re: .* entries in official release source tarballs
From: Jan Beulich @ 2010-10-08 7:02 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <19629.63891.993200.856801@mariner.uk.xensource.com>
>>> On 07.10.10 at 18:47, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[Xen-devel] .* entries in official release source
> tarballs"):
>> Since these are - afaict - meaningless outside of mercurial, would it be
>> possible to drop them when creating the tarballs?
>
> It would be possible but I don't think it's a good idea. The more
> steps are involved in creating the official release tarballs, the more
> likely it is that something will go wrong.
>
> Are these files causing some kind of problem for you ?
No, not a problem really - they're just confusing/meaningless there
(just like I thing .*ignore files scattered around source trees don't
belong in release tarballs).
Jan
^ permalink raw reply
* Re: [PATCH 03/18] fs: keep inode with backing-dev
From: Christoph Hellwig @ 2010-10-08 7:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-4-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:17PM +1100, Dave Chinner wrote:
> From: Nick Piggin <npiggin@suse.de>
>
> Having inode on writeback lists of a different bdi than
> inode->i_mapping->backing_dev_info makes it very difficult to do
> per-bdi locking of the writeback lists. Add functions to move these
> inodes over when the mapping backing dev is changed.
>
> Also, rename i_mapping.backing_dev_info to i_mapping.a_bdi while we're
> here. Succinct is nice, and it catches conversion errors.
NAK. This is fixed by my patch to always use s_bdi for writeback
purposed that hit Linus' tree two days ago.
^ permalink raw reply
* Re: [Xenomai-help] kernel oopses when killing realtime task
From: Pavel Machek @ 2010-10-08 7:01 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
In-Reply-To: <4CADBDC2.8080600@domain.hid>
Hi!
> > I have... quite an interesting setup here.
> >
> > SMP machine, with special PCI card; that card has GPIOs and serial
> > ports. Unfortunately, there's only one interrupt, shared between
> > serials and GPIO pins, and serials are way too complex to be handled
> > by realtime layer.
> >
> > So I ended up with
> >
> > // we also have an interrupt handler:
> > ret = rtdm_irq_request(&my_context->irq_handle,
> > gpio_rt_config.irq, demo_interrupt,
> > RTDM_IRQTYPE_SHARED,
> > context->device->proc_name, my_context);
> >
> > and
> >
> > static int demo_interrupt(rtdm_irq_t *irq_context)
> > {
> > struct demodrv_context *ctx;
> > int dev_id;
> > int ret = RTDM_IRQ_HANDLED; // usual return value
> > unsigned pending, output;
> >
> > ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
> > dev_id = ctx->dev_id;
> >
> > if (!ctx->ready) {
> > printk(KERN_CRIT "Unexpected interrupt\n");
> > return XN_ISR_PROPAGATE;
>
> Who sets ready and when? Looks racy.
Debugging aid; yes, this one is racy.
> > rtdm_lock_put(&ctx->lock);
> >
> > /* We need to propagate the interrupt, so that PMC-6L serials
> > work. Result is that interrupt latencies can't be
> > guaranteed when serials are in use. */
> >
> > return RTDM_IRQ_HANDLED;
> > }
> >
> > Unregistration is:
> > my_context->ready = 0;
> > rtdm_irq_disable(&my_context->irq_handle);
>
> Where is rtdm_irq_free? Again, this ready flag looks racy.
Aha, sorry, I quoted wrong snippet. rtdm_irq_free() follows
immediately, like this:
int demo_close_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info)
{
struct demodrv_context *my_context;
rtdm_lockctx_t lock_ctx;
// get the context
my_context = (struct demodrv_context *)context->dev_private;
// if we need to do some stuff with preemption disabled:
rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
my_context->ready = 0;
rtdm_irq_disable(&my_context->irq_handle);
// free irq in RTDM
rtdm_irq_free(&my_context->irq_handle);
// destroy our interrupt signal/event
rtdm_event_destroy(&my_context->irq_event);
// other stuff here
rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
return 0;
}
Now... I'm aware that lock_get/put around irq_free should be
unneccessary, as should be irq_disable and my ->ready flag. Those were
my attempts to work around the problem. I'll attach the full source at
the end.
> > Unfortunately, when the userspace app is ran and killed repeatedly (so
> > that interrupt is registered/unregistered all the time), I get
> > oopses in __ipipe_dispatch_wired() -- it seems to call into the NULL
> > pointer.
> >
> > I decided that "wired" interrupt when the source is shared between
> > Linux and Xenomai, is wrong thing, so I disable "wired" interrupts
> > altogether, but that only moved oops to __virq_end.
>
> This is wrong. The only way to get a determistically shared IRQs across
> domains is via the wired path, either using the pattern Gilles cited or,
> in a slight variation, signaling down via a separate rtdm_nrtsig.
For now, I'm trying to get it not to oops; deterministic latencies are
the next topic :-(.
The hardware is little unusual that it generates interrupts at 1kHz,
whether realtime driver is loaded or not.
Pavel
/**********************************************************/
/* HARD REAL TIME RTDM Driver Skeleton V1.1 */
/* */
/* Based on code of Jan Kiszka - thanks Jan! */
/* (C) 2006 Jan Kiszka, www.captain.at */
/* (C) 2010 Pavel Machek, sysgo */
/* License: GPL */
/**********************************************************/
/* Note: Interrupt is shared between serial lines and GPIOs. That
means that interrupt latencies can't be guaranteed when serials are
in use.
*/
#include <linux/mman.h>
#include <rtdm/rtdm_driver.h>
#include "pmc6l-rt.h"
char dummy_buffer[BUFSIZE];
int events;
// our driver context struct: used for storing various information
struct demodrv_context {
rtdm_irq_t irq_handle;
rtdm_lock_t lock;
int dev_id;
u64 last_timestamp;
rtdm_event_t irq_event;
volatile unsigned long irq_event_lock;
volatile int irq_events;
int64_t timeout;
void *buf;
int ready;
};
#define GPIO_CONF_LOW 0xb0
#define GPIO_CONF_HIGH 0xb2
#define GPIO_STATUS_IN 0xb4
#define GPIO_STATUS_OUT 0xb6
#define GPIO_IRQ_ID 0x2a
#define iowrite(bits, val, adr) iowrite##bits(cpu_to_be##bits(val), adr)
#define ioread(bits, adr) be##bits##_to_cpu(ioread##bits(adr))
#define pgwrite(dat, adr) iowrite(16, (dat), gpio_rt_config.mmio+(adr))
#define pgread(adr) ioread(16, gpio_rt_config.mmio+(adr))
/**********************************************************/
/* INTERRUPT HANDLING */
/**********************************************************/
/*
* Demo interrupt code; when GPIO #2 is changed, GPIO #4 is toggled.
*/
static int demo_interrupt(rtdm_irq_t *irq_context)
{
struct demodrv_context *ctx;
int dev_id;
int ret = RTDM_IRQ_HANDLED; // usual return value
unsigned pending, output;
ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
dev_id = ctx->dev_id;
if (!ctx->ready) {
printk(KERN_CRIT "Unexpected interrupt\n");
return XN_ISR_PROPAGATE;
}
#if 0
rtdm_lock_get(&ctx->lock);
pending = pgread(GPIO_IRQ_ID);
pgwrite(0, GPIO_IRQ_ID);
output = pgread(GPIO_STATUS_OUT);
output ^= (1<<3);
pgwrite(output, GPIO_STATUS_OUT);
// do stuff
if (events > 1000) {
rtdm_event_signal(&ctx->irq_event);
events = 0;
}
events++;
rtdm_lock_put(&ctx->lock);
// those return values were dropped from the RTDM
// ret = RTDM_IRQ_ENABLE | RTDM_IRQ_PROPAGATE;
/* We need to propagate the interrupt, so that PMC-6L serials
work. Result is that interrupt latencies can't be
guaranteed when serials are in use. */
// return XN_ISR_PROPAGATE;
return RTDM_IRQ_HANDLED;
#else
pending = pgread(GPIO_IRQ_ID);
pgwrite(0, GPIO_IRQ_ID);
output = pgread(GPIO_STATUS_OUT);
output = output & (~(1<<3));
if (pgread(GPIO_STATUS_IN) & (1<<1))
output |= (1<<3);
pgwrite(output, GPIO_STATUS_OUT);
// those return values were dropped from the RTDM
// ret = RTDM_IRQ_ENABLE | RTDM_IRQ_PROPAGATE;
/* We need to propagate the interrupt, so that PMC-6L serials
work. Result is that interrupt latencies can't be
guaranteed when serials are in use. */
// return XN_ISR_PROPAGATE;
return RTDM_IRQ_HANDLED;
#endif
}
/**********************************************************/
/* DRIVER OPEN */
/**********************************************************/
int demo_open_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info,
int oflags)
{
struct demodrv_context *my_context;
int dev_id = context->device->device_id;
int ret;
// get the context for our driver - used to store driver info
my_context = (struct demodrv_context *)context->dev_private;
// we also have an interrupt handler:
ret = rtdm_irq_request(&my_context->irq_handle, gpio_rt_config.irq, demo_interrupt,
RTDM_IRQTYPE_SHARED, context->device->proc_name, my_context);
if (ret < 0)
return ret;
/* IPC initialisation - cannot fail with used parameters */
rtdm_lock_init(&my_context->lock);
rtdm_event_init(&my_context->irq_event, 0);
my_context->dev_id = dev_id;
my_context->irq_events = 0;
my_context->irq_event_lock = 0;
my_context->ready = 1;
my_context->timeout = 0; // wait INFINITE
// enable interrupt in RTDM
rtdm_irq_enable(&my_context->irq_handle);
return 0;
}
/**********************************************************/
/* DRIVER CLOSE */
/**********************************************************/
int demo_close_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info)
{
struct demodrv_context *my_context;
rtdm_lockctx_t lock_ctx;
// get the context
my_context = (struct demodrv_context *)context->dev_private;
// if we need to do some stuff with preemption disabled:
rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
my_context->ready = 0;
rtdm_irq_disable(&my_context->irq_handle);
// free irq in RTDM
rtdm_irq_free(&my_context->irq_handle);
// destroy our interrupt signal/event
rtdm_event_destroy(&my_context->irq_event);
// other stuff here
rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
return 0;
}
/**********************************************************/
/* DRIVER READ */
/**********************************************************/
int demo_read_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info, void *buf, size_t nbyte)
{
struct demodrv_context *ctx;
int dev_id;
char *out_pos = (char *)buf;
rtdm_toseq_t timeout_seq;
int ret;
// zero bytes requested ? return!
if (nbyte == 0)
return 0;
// check if R/W actions to user-space are allowed
if (user_info && !rtdm_rw_user_ok(user_info, buf, nbyte))
return -EFAULT;
ctx = (struct demodrv_context *)context->dev_private;
dev_id = ctx->dev_id;
// wait: if ctx->timeout = 0, it will block infintely until
// rtdm_event_signal(&ctx->irq_event); is called from our
// interrupt routine
ret = rtdm_event_timedwait(&ctx->irq_event, ctx->timeout, &timeout_seq);
// now write the requested stuff to user-space
if (rtdm_copy_to_user(user_info, out_pos,
dummy_buffer, BUFSIZE) != 0) {
ret = -EFAULT;
} else {
ret = BUFSIZE;
}
return ret;
}
/**********************************************************/
/* DRIVER OPERATIONS */
/**********************************************************/
static struct rtdm_device demo_device = {
struct_version: RTDM_DEVICE_STRUCT_VER,
device_flags: RTDM_NAMED_DEVICE,
context_size: sizeof(struct demodrv_context),
device_name: DEV_FILE,
/* open and close functions are not real-time safe due kmalloc
and kfree. If you do not use kmalloc and kfree, and you made
sure that there is no syscall in the open/close handler, you
can declare the open_rt and close_rt handler.
*/
open_rt: NULL,
open_nrt: demo_open_rt,
ops: {
close_rt: NULL,
close_nrt: demo_close_rt,
ioctl_rt: NULL,
ioctl_nrt: NULL,
read_rt: demo_read_rt,
read_nrt: NULL,
write_rt: NULL,
write_nrt: NULL,
recvmsg_rt: NULL,
recvmsg_nrt: NULL,
sendmsg_rt: NULL,
sendmsg_nrt: NULL,
},
device_class: RTDM_CLASS_EXPERIMENTAL,
device_sub_class: 222,
driver_name: DRV_NAME,
peripheral_name: DEV_FILE_NAME,
provider_name: "-",
proc_name: demo_device.device_name,
};
/**********************************************************/
/* INIT DRIVER */
/**********************************************************/
int init_module(void)
{
pmc_gpio_rt_config();
printk("realtime driver at irq %d mmio %x\n",
gpio_rt_config.irq, gpio_rt_config.mmio);
return rtdm_dev_register(&demo_device);
}
/**********************************************************/
/* CLEANUP DRIVER */
/**********************************************************/
void cleanup_module(void)
{
rtdm_dev_unregister(&demo_device, 1000);
}
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("RTDM Real Time Driver Example");
--- user app ----
/**********************************************************/
/* HARD REAL TIME RTDM Driver User-Space Application */
/* */
/* Based on code of Jan Kiszka - thanks Jan! */
/* (C) 2006 Jan Kiszka, www.captain.at */
/* (C) 2010 Pavel Machek, sysgo */
/* License: GPL */
/**********************************************************/
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/mman.h>
#include <native/task.h>
#include <native/timer.h>
#include <rtdm/rtdm.h>
#include "pmc6l-rt.h"
unsigned int my_state = 0;
int timer_started = 0;
int my_fd = -1;
int shutdownnow = 0;
RT_TASK my_task;
// --s-ms-us-ns
RTIME my_task_period_ns = 1000000000llu;
/**********************************************************/
/* CLOSE RT DRIVER */
/**********************************************************/
static int close_file( int fd, unsigned char *name) {
int ret,i=0;
do {
i++;
ret = rt_dev_close(fd);
switch(-ret){
case EBADF: printf("%s -> invalid fd or context\n",name);
break;
case EAGAIN: printf("%s -> EAGAIN (%d times)\n",name,i);
rt_task_sleep(50000); // wait 50us
break;
case 0: printf("%s -> closed\n",name);
break;
default: printf("%s -> ???\n",name);
break;
}
} while (ret == -EAGAIN && i < 10);
return ret;
}
/**********************************************************/
/* CLEANING UP */
/**********************************************************/
void cleanup_all(void) {
if (my_state & STATE_FILE_OPENED) {
close_file( my_fd, DEV_FILE " (user)");
my_state &= ~STATE_FILE_OPENED;
}
if (my_state & STATE_TASK_CREATED) {
printf("delete my_task\n");
rt_task_delete(&my_task);
my_state &= ~STATE_TASK_CREATED;
}
if (timer_started) {
printf("stop timer\n");
rt_timer_stop();
}
}
void catch_signal(int sig) {
shutdownnow = 1;
cleanup_all();
printf("exit\n");
return;
}
/**********************************************************/
/* REAL TIME TASK */
/**********************************************************/
void my_task_proc(void *arg) {
int ret;
ssize_t sz = sizeof(RTIME);
ssize_t written = 0;
ssize_t read = 0;
int counter = 0;
int readbackcounter;
unsigned char buf[17] = "CAPTAIN WAS HERE\0";
unsigned char buf2[17] = "XXXXXXXXXXXXXXXX\0";
/* no periodic task, due blocking read from the RT driver (see below too)
ret = rt_task_set_periodic(NULL, TM_NOW, rt_timer_ns2ticks(my_task_period_ns));
if (ret) {
printf("error while set periodic, code %d\n",ret);
goto exit_my_task;
}
*/
while (1) {
sprintf(buf, "CAPTAIN %d", counter);
counter++;
if (counter > 100) counter = 0;
/* switch to primary mode */
ret = rt_task_set_mode(0, T_PRIMARY, NULL);
if (ret) {
printf("error while rt_task_set_mode, code %d\n",ret);
goto exit_my_task;
}
sz = sizeof(buf2);
read = rt_dev_read(my_fd, &buf2, sizeof(buf2));
if (read == sz ) {
printf("READ: read=%s\n",buf2);
} else {
if (read < 0 ) {
printf("error while rt_dev_read, code %d\n",read);
} else {
printf("only %d / %d byte received \n",read,sz);
}
}
// read blocks, so check if user hit CTRL-C meanwhile
// otherwise we segfault when mmap'ing
if (shutdownnow == 1) break;
}
exit_my_task:
if (my_state & STATE_FILE_OPENED) {
if (!close_file( my_fd, DEV_FILE " (write)")) {
my_state &= ~STATE_FILE_OPENED;
}
}
printf("exit\n");
}
/**********************************************************/
/* MAIN: mainly RT task initialization */
/**********************************************************/
int main(int argc, char* argv[]) {
int ret = 0;
signal(SIGTERM, catch_signal);
signal(SIGINT, catch_signal);
printf("PRESS CTRL-C to EXIT\n");
/* no memory-swapping for this programm */
mlockall(MCL_CURRENT | MCL_FUTURE);
/* start timer */
ret = rt_timer_start(TM_ONESHOT);
switch (ret) {
case 0: printf("timer started\n");
timer_started = 1;
break;
case -EBUSY: printf("timer is running\n");
timer_started = 0;
break;
case -ENOSYS: printf("can't start timer\n");
return ret;
}
/* open DEV_FILE */
my_fd = rt_dev_open( DEV_FILE, 0);
if (my_fd < 0) {
printf("can't open %s\n", DEV_FILE);
goto error;
}
my_state |= STATE_FILE_OPENED;
printf("%s opened\n", DEV_FILE);
/* create my_task */
ret = rt_task_create(&my_task,"my_task",0,50,0);
if (ret) {
printf("failed to create my_task, code %d\n",ret);
goto error;
}
my_state |= STATE_TASK_CREATED;
printf("my_task created\n");
/* start my_task */
printf("starting my_task\n");
ret = rt_task_start(&my_task,&my_task_proc,NULL);
if (ret) {
printf("failed to start my_task, code %d\n",ret);
goto error;
}
pause();
return 0;
error:
cleanup_all();
return ret;
}
^ permalink raw reply
* Pour votre securité faites confiance au numero 1 Europeen
From: SD Telesurveillance par Plein Temps @ 2010-10-08 7:01 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
^ permalink raw reply
* Re: [PATCH 02/18] fs: Convert nr_inodes and nr_unused to per-cpu counters
From: Christoph Hellwig @ 2010-10-08 7:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-3-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:16PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> The number of inodes allocated does not need to be tied to the
> addition or removal of an inode to/from a list. If we are not tied
> to a list lock, we could update the counters when inodes are
> initialised or destroyed, but to do that we need to convert the
> counters to be per-cpu (i.e. independent of a lock). This means that
> we have the freedom to change the list/locking implementation
> without needing to care about the counters.
>
> Based on a patch originally from Eric Dumazet.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
Looks good except for a spurious whitespace change in inode_init_early.
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ 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.