* Re: DM365 McBSP as Master
From: Clemens Ladisch @ 2011-10-24 18:40 UTC (permalink / raw)
To: Appalayagari Sreedhar
Cc: alsa-devel, Mark Brown, Liam Girdwood, Vladimir Barinov
In-Reply-To: <CAODvfaE1Sp-=GYx=A3tM55Xn+hWTQzb4NmH+3nnn0F0jznwniA@mail.gmail.com>
Appalayagari Sreedhar wrote:
> Thank you very much. but for the tlv320aic3x codec it works.
> tlv320aic3x device is also duplex device. and also after aplay
> calling, i can succesfully open the device for my codec driver.
> could you please tell me what i am missing and also why it is working
> for the tlv320aic3x device.
There's probably some difference in the behaviour of the two drivers
regarding multiple opens. Which drivers are you using (the codecs
don't matter)?
Regards,
Clemens
^ permalink raw reply
* Re: [PATCH 9/9] ib_srpt: Convert srpt_sq_size into per port configfs attribute
From: Nicholas A. Bellinger @ 2011-10-24 18:39 UTC (permalink / raw)
To: Bart Van Assche; +Cc: linux-rdma, Roland Dreier, target-devel, linux-scsi
In-Reply-To: <CAO+b5-qZHTEy25E0uR9yzAjAdvOH-k2_+ga4J_CUNTdUFyihZQ@mail.gmail.com>
On Mon, 2011-10-24 at 20:32 +0200, Bart Van Assche wrote:
> On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> > @@ -2144,11 +2140,11 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
> > goto out;
> >
> > ch->cq = ib_create_cq(sdev->device, srpt_completion, NULL, ch,
> > - ch->rq_size + srpt_sq_size, 0);
> > + ch->rq_size + sport->port_attrib.srp_sq_size, 0);
> > if (IS_ERR(ch->cq)) {
> > ret = PTR_ERR(ch->cq);
> > printk(KERN_ERR "failed to create CQ cqe= %d ret= %d\n",
> > - ch->rq_size + srpt_sq_size, ret);
> > + ch->rq_size + sport->port_attrib.srp_sq_size, ret);
> > goto out;
> > }
> >
> > @@ -2160,7 +2156,7 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
> > qp_init->srq = sdev->srq;
> > qp_init->sq_sig_type = IB_SIGNAL_REQ_WR;
> > qp_init->qp_type = IB_QPT_RC;
> > - qp_init->cap.max_send_wr = srpt_sq_size;
> > + qp_init->cap.max_send_wr = sport->port_attrib.srp_sq_size;
> > qp_init->cap.max_send_sge = SRPT_DEF_SG_PER_WQE;
>
> This patch introduces a race condition: if
> sport->port_attrib.srp_sq_size is modified from user space while an
> SRP login is ongoing then different values of that parameter can be
> used in each of the above statements that read that parameter while
> they all should use the same value.
>
Fair point. Fixing this up now.
Also, please stop dropping relevant list CC'ed from my patches.
Thanks,
--nab
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 3/4] Add cap reduction support to enable use as SUID
From: Corey Bryant @ 2011-10-24 18:38 UTC (permalink / raw)
To: Blue Swirl; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <CAAu8pHu45eWhUK146Qp2f8VNA02kNq7=XqWkx8ynT2Madm2xsA@mail.gmail.com>
On 10/24/2011 01:10 PM, Blue Swirl wrote:
> On Mon, Oct 24, 2011 at 14:13, Corey Bryant<coreyb@linux.vnet.ibm.com> wrote:
>>
>>
>> On 10/23/2011 09:22 AM, Blue Swirl wrote:
>>>
>>> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com>
>>> wrote:
>>>>
>>>> The ideal way to use qemu-bridge-helper is to give it an fscap of using:
>>>>
>>>> setcap cap_net_admin=ep qemu-bridge-helper
>>>>
>>>> Unfortunately, most distros still do not have a mechanism to package
>>>> files
>>>> with fscaps applied. This means they'll have to SUID the
>>>> qemu-bridge-helper
>>>> binary.
>>>>
>>>> To improve security, use libcap to reduce our capability set to just
>>>> cap_net_admin, then reduce privileges down to the calling user. This is
>>>> hopefully close to equivalent to fscap support from a security
>>>> perspective.
>>>>
>>>> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>>>> Signed-off-by: Richa Marwaha<rmarwah@linux.vnet.ibm.com>
>>>> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>>>> ---
>>>> configure | 34 ++++++++++++++++++++++++++++++++++
>>>> qemu-bridge-helper.c | 39 +++++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 73 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/configure b/configure
>>>> index 6c8b659..fed66b0 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -128,6 +128,7 @@ vnc_thread="no"
>>>> xen=""
>>>> xen_ctrl_version=""
>>>> linux_aio=""
>>>> +cap=""
>>>> attr=""
>>>> xfs=""
>>>>
>>>> @@ -653,6 +654,10 @@ for opt do
>>>> ;;
>>>> --enable-kvm) kvm="yes"
>>>> ;;
>>>> + --disable-cap) cap="no"
>>>> + ;;
>>>> + --enable-cap) cap="yes"
>>>> + ;;
>>>> --disable-spice) spice="no"
>>>> ;;
>>>> --enable-spice) spice="yes"
>>>> @@ -1032,6 +1037,8 @@ echo " --disable-vde disable support
>>>> for vde network"
>>>> echo " --enable-vde enable support for vde network"
>>>> echo " --disable-linux-aio disable Linux AIO support"
>>>> echo " --enable-linux-aio enable Linux AIO support"
>>>> +echo " --disable-cap disable libcap-ng support"
>>>> +echo " --enable-cap enable libcap-ng support"
>>>> echo " --disable-attr disables attr and xattr support"
>>>> echo " --enable-attr enable attr and xattr support"
>>>> echo " --disable-blobs disable installing provided firmware
>>>> blobs"
>>>> @@ -1638,6 +1645,29 @@ EOF
>>>> fi
>>>>
>>>> ##########################################
>>>> +# libcap-ng library probe
>>>> +if test "$cap" != "no" ; then
>>>> + cap_libs="-lcap-ng"
>>>> + cat> $TMPC<< EOF
>>>> +#include<cap-ng.h>
>>>> +int main(void)
>>>> +{
>>>> + capng_capability_to_name(CAPNG_EFFECTIVE);
>>>> + return 0;
>>>> +}
>>>> +EOF
>>>> + if compile_prog "" "$cap_libs" ; then
>>>> + cap=yes
>>>> + libs_tools="$cap_libs $libs_tools"
>>>> + else
>>>> + if test "$cap" = "yes" ; then
>>>> + feature_not_found "cap"
>>>> + fi
>>>> + cap=no
>>>> + fi
>>>> +fi
>>>> +
>>>> +##########################################
>>>> # Sound support libraries probe
>>>>
>>>> audio_drv_probe()
>>>> @@ -2735,6 +2765,7 @@ echo "fdatasync $fdatasync"
>>>> echo "madvise $madvise"
>>>> echo "posix_madvise $posix_madvise"
>>>> echo "uuid support $uuid"
>>>> +echo "libcap-ng support $cap"
>>>> echo "vhost-net support $vhost_net"
>>>> echo "Trace backend $trace_backend"
>>>> echo "Trace output file $trace_file-<pid>"
>>>> @@ -2846,6 +2877,9 @@ fi
>>>> if test "$vde" = "yes" ; then
>>>> echo "CONFIG_VDE=y">> $config_host_mak
>>>> fi
>>>> +if test "$cap" = "yes" ; then
>>>> + echo "CONFIG_LIBCAP=y">> $config_host_mak
>>>> +fi
>>>> for card in $audio_card_list; do
>>>> def=CONFIG_`echo $card | tr '[:lower:]' '[:upper:]'`
>>>> echo "$def=y">> $config_host_mak
>>>> diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>>>> index db257d5..b1562eb 100644
>>>> --- a/qemu-bridge-helper.c
>>>> +++ b/qemu-bridge-helper.c
>>>> @@ -33,6 +33,10 @@
>>>>
>>>> #include "net/tap-linux.h"
>>>>
>>>> +#ifdef CONFIG_LIBCAP
>>>> +#include<cap-ng.h>
>>>> +#endif
>>>> +
>>>> #define MAX_ACLS (128)
>>>> #define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
>>>>
>>>> @@ -185,6 +189,27 @@ static int send_fd(int c, int fd)
>>>> return sendmsg(c,&msg, 0);
>>>> }
>>>>
>>>> +#ifdef CONFIG_LIBCAP
>>>> +static int drop_privileges(void)
>>>> +{
>>>> + /* clear all capabilities */
>>>> + capng_clear(CAPNG_SELECT_BOTH);
>>>> +
>>>> + if (capng_update(CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED,
>>>> + CAP_NET_ADMIN)< 0) {
>>>> + return -1;
>>>> + }
>>>> +
>>>> + /* change to calling user's real uid and gid, retaining supplemental
>>>> + * groups and CAP_NET_ADMIN */
>>>> + if (capng_change_id(getuid(), getgid(), CAPNG_CLEAR_BOUNDING)) {
>>>> + return -1;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +#endif
>>>> +
>>>> int main(int argc, char **argv)
>>>> {
>>>> struct ifreq ifr;
>>>> @@ -198,6 +223,20 @@ int main(int argc, char **argv)
>>>> int acl_count = 0;
>>>> int i, access_allowed, access_denied;
>>>>
>>>> + /* if we're run from an suid binary, immediately drop privileges
>>>> preserving
>>>> + * cap_net_admin -- exit immediately if libcap not configured */
>>>> + if (geteuid() == 0&& getuid() != geteuid()) {
>>>> +#ifdef CONFIG_LIBCAP
>>>> + if (drop_privileges() == -1) {
>>>> + fprintf(stderr, "failed to drop privileges\n");
>>>> + return 1;
>>>> + }
>>>> +#else
>>>> + fprintf(stderr, "failed to drop privileges\n");
>>>
>>> This makes the tool useless without CONFIG_LIBCAP. Wouldn't it be
>>> possible to use setfsuid() instead for Linux?
>>>
>>> Some fork+setuid helper could be used for other Unix and for the lame
>>> OSes without any file system DAC capabilities, a different syntax that
>>> does not rely on underlying FS may need to be introduced. Again, I
>>> don't know if the tool is even interesting for non-Linux.
>>>
>>
>> I just want to make sure that there is no chance that the helper is run as
>> root beyond this point. Are you saying to seteuid(getuid) and
>> setfsuid(root)? I'm not sure that would drop the privileges enough.
>
> Without capabilities, we can't drop root privileges because bridge
> setup would fail otherwise, but we could use setfsuid(getuid()) and
> setfsgid(getgid()) during file access so permission checks work.
> Perhaps non-Linux could use seteuid() etc. instead.
>
This would reduce file system access from effective UID/GID (root/root)
to real UID/GID (non-root/non-root). Other than file system access, the
helper would still run under root/root, right? I don't think we want
that from a security aspect.
--
Regards,
Corey
>>>> + return 1;
>>>> +#endif
>>>> + }
>>>> +
>>>> /* parse arguments */
>>>> if (argc< 3 || argc> 4) {
>>>> fprintf(stderr, "Usage: %s [--use-vnet] BRIDGE FD\n", argv[0]);
>>>> --
>>>> 1.7.3.4
>>>>
>>>>
>>>>
>>>
^ permalink raw reply
* Re: [PATCH] usb: fix unaligned access
From: Fabian van der Werf @ 2011-10-24 18:37 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20111024170753.GN23421@pengutronix.de>
On Mon, Oct 24, 2011 at 7:07 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Oct 24, 2011 at 07:14:04PM +0400, Antony Pavlov wrote:
>> On 23 October 2011 13:29, Fabian van der Werf <fvanderwerf@gmail.com> wrote:
>> >>
>> >> Looks like a valid patch, I wonder that this never was a problem before.
>> >> ARM should break here aswell I think. What architecture are you using?
>> >>
>> >
>> > I am working with a pandaboard (arm cortex a9). The pandaboard has a
>> > usb ethernet controller, so I need usb to boot over tftp. I guess that
>> > most arm configurations don't need usb for booting, and in that case
>> > you won't run into this problem.
>>
>> I have DUB-E100 USB Ethernet (ID 2001:3c05) connected to Toshiba AC100
>> (NVidia Tegra2 --- Cortex A9); tftp works fine without usb unaligned
>> access patch.
>
> Works for me aswell, though the access definitely is unaligned.
>
Okay, I think it may be a compiler problem. The latest code sourcery
compiler builds a barebox that breaks on usb. 2009q1-203 builds fine,
however.
In the usb code the compiler should be able to figure out that the
access is unaligned from the packed structure. So I guess it should
split up the access in multiple loads/stores. I will look into the
binaries to confirm this. The latest compiler may be broken or maybe
the default behaviour has changed because armv7 actually supports
unaligned access.
Fabian
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Building for TI 8148 EVM
From: Denys Dmytriyenko @ 2011-10-24 18:37 UTC (permalink / raw)
To: meta-ti
In-Reply-To: <A9FC6A94-E05C-4396-807B-A71CC08B9B40@dominion.thruhere.net>
On Mon, Oct 24, 2011 at 01:22:54PM +0200, Koen Kooi wrote:
>
> Op 24 okt. 2011, om 11:05 heeft Rainer Koenig het volgende geschreven:
>
> > Koen,
> > Am 24.10.2011 10:58, schrieb Koen Kooi:
> >>> Tried this over the weekend on my home PC. Yes, works. But I was just
> >>> able to build a console image. The build of systemd-gnome-image fails
> >>> with the error that nothing provides "DRI". MACHINE=dm8148-evm.
> >>
> >> I'm not seeing that with this set of metadata:
> >> Could you please share your version of that so we can see if there are
> >> fixes missing?
> >
> > Difficult at the moment because now I'm back to work and the data is at
> > home. :-) But I will setup this again on my work machine and see that I
> > get the firewall-issues solved, so I should be able to reproduce my
> > results.
>
> Roger provided a log with a related looking bug, which should get solved
> Real Soon(TM) when the following gets applied:
>
> http://patchwork.openembedded.org/patch/13783/
>
> In the mean time you should be able to get around it by doing 'bitbake
> mesa-dri' manually.
Yep, I can confirm this issue. I had it fixed locally by adding mesa-dri to
DEPENDS in xorg-xserver... Didn't have time to submit either a patch or a
bugreport though.
--
Denys
^ permalink raw reply
* Re: [PATCH-v2] ib_srpt: Initial SRP Target merge for v3.2-rc1
From: Nicholas A. Bellinger @ 2011-10-24 18:33 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-rdma, Roland Dreier, Christoph Hellwig, Vu Pham,
David Dillow, target-devel, linux-scsi
In-Reply-To: <CAO+b5-rch-mPgXKjs4=t4ubfb9SFhDiR26EoeJgyZjWfhRJ9DA@mail.gmail.com>
On Mon, 2011-10-24 at 18:45 +0200, Bart Van Assche wrote:
> On Mon, Oct 24, 2011 at 7:57 AM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> > This v2 patch adds the kernel module ib_srpt SCSI RDMA Protocol (SRP) target
> > implementation conforming to the SRP r16a specification for the mainline
> > drivers/target infrastructure.
> >
> > This driver was originally developed by Vu Pham and has been optimized by
> > Bart Van Assche and merged into upstream LIO based on his srpt-lio-4.1 branch.
> > This patch is made against the current pending target-core changes for
> > v3.2-rc1, the full tree is available here:
>
> Maybe you remember that the reason why I developed this patch was to
> be able to run performance measurements ? The following changes are
> necessary to convert this patch into a robust kernel driver:
> - Handle the case where the last WQE event arrives before the
> corresponding queue pair is reset (r3870 in the SCST SVN repo).
> - Handle IB completion timeouts. Although the InfiniBand Architecture
> Manual specifies that a HCA must generate an error completion for each
> pending work item when a queue pair reset is issued, an important
> class of HCAs doesn't do this (that includes the HCA in your test
> setup). In the SCST version of this driver such timeouts are handled
> by the function srpt_pending_cmd_timeout().
>
> Both issues mentioned above can lead to sessions not being cleaned up
> properly and hence all future logins from the initiator associated
> with that session to be blocked.
>
It would have been nice if you bothered to mention these in any of the
pre merge window reviews, but given your delay responsed on these items
they will have to be something we'll fix post merge.
Thanks,
--nab
^ permalink raw reply
* Re: [PATCH 9/9] ib_srpt: Convert srpt_sq_size into per port configfs attribute
From: Bart Van Assche @ 2011-10-24 18:32 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-rdma, Roland Dreier
In-Reply-To: <1319434422-15354-10-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger
<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org> wrote:
> @@ -2144,11 +2140,11 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
> goto out;
>
> ch->cq = ib_create_cq(sdev->device, srpt_completion, NULL, ch,
> - ch->rq_size + srpt_sq_size, 0);
> + ch->rq_size + sport->port_attrib.srp_sq_size, 0);
> if (IS_ERR(ch->cq)) {
> ret = PTR_ERR(ch->cq);
> printk(KERN_ERR "failed to create CQ cqe= %d ret= %d\n",
> - ch->rq_size + srpt_sq_size, ret);
> + ch->rq_size + sport->port_attrib.srp_sq_size, ret);
> goto out;
> }
>
> @@ -2160,7 +2156,7 @@ static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
> qp_init->srq = sdev->srq;
> qp_init->sq_sig_type = IB_SIGNAL_REQ_WR;
> qp_init->qp_type = IB_QPT_RC;
> - qp_init->cap.max_send_wr = srpt_sq_size;
> + qp_init->cap.max_send_wr = sport->port_attrib.srp_sq_size;
> qp_init->cap.max_send_sge = SRPT_DEF_SG_PER_WQE;
This patch introduces a race condition: if
sport->port_attrib.srp_sq_size is modified from user space while an
SRP login is ongoing then different values of that parameter can be
used in each of the above statements that read that parameter while
they all should use the same value.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [DVB] Digital Devices Cine CT V6 support
From: Ralph Metzler @ 2011-10-24 18:31 UTC (permalink / raw)
To: Sébastien RAILLARD; +Cc: 'Linux Media Mailing List'
In-Reply-To: <004e01cc9247$0a8da4d0$1fa8ee70$@coexsi.fr>
Sébastien RAILLARD (COEXSI) writes:
> I've seen a new parameter "ts_loop", can you explain how it's working?
> Is-it for sending the stream from the demodulator directly to the CAM
> reader?
No, it is mainly for testing. It declares one TAB as loopback, which
means that the data output is directly connected to the input.
For redirecting a stream through a CI see the "redirect" attribute.
I don't know if my small redirect readme was included in the package I
sent to Oliver. So, I attached it below.
-Ralph
Redirection of TS streams through CI modules is now supported
through /sys/class/ddbridge/ddbridge0/redirect.
It only works with cards based on the ddbridge PCIe bridge, not
with nGene based cards.
It is set up in such a way that you can write "AB CD" to
a "redirect" attribute and data from input B of card A is then piped through
port D (meaning TAB (D+1) which uses output D and input 2*D for CI io)
of card C and then shows up in the demux device belonging to
input B (input (B&1) of TAB (B/2+1)) of card A.
E.g.:
echo "00 01" > /sys/class/ddbridge/ddbridge0/redirect
will pipe input 0 of card 0 through CI at port 1 (TAB 2) of card 0.
Redirection should only be done right after loading the driver
(or booting if the driver is built-in) and before using the
devices in any way.
^ permalink raw reply
* Re: [meta-xfce 3/3] xfce4-datetime-plugin: Initial add git (0.6.1)
From: Paul Menzel @ 2011-10-24 18:24 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1319480061-20128-3-git-send-email-schnitzeltony@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
Dear Andreas,
Am Montag, den 24.10.2011, 20:14 +0200 schrieb Andreas Müller:
> Version 0.6.1 was release about 3 years ago. The patch to migrate from
> libxfcegui4->libxfce4ui hopefully shall be applied mainline [1]. It would have
> caused extra efforts to base the patch on 0.6.1 release.
>
> [1] https://bugzilla.xfce.org/show_bug.cgi?id=8064
>
> Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
> ---
> .../datetime/files/port-to-libxfce4ui.patch | 360 ++++++++++++++++++++
> .../datetime/xfce4-datetime-plugin_git.bb | 20 ++
> 2 files changed, 380 insertions(+), 0 deletions(-)
> create mode 100644 meta-xfce/recipes-panel-plugins/datetime/files/port-to-libxfce4ui.patch
> create mode 100644 meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb
[…]
> diff --git a/meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb b/meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb
> new file mode 100644
> index 0000000..831d549
> --- /dev/null
> +++ b/meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb
> @@ -0,0 +1,20 @@
> +DESCRIPTION = "Panel plugin to date and time anc calendar when clicked"
the description could be improved if I am right.
Panel plugin displaying date and time and a calendar when left-clicked.
[…]
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6
From: bugzilla-daemon @ 2011-10-24 18:30 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42117-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #4 from Roland Scheidegger <sroland@vmware.com> 2011-10-24 11:30:14 PDT ---
Some performance difference is expected due to kms not supporting tiling on
r200, though I would expect a 2x difference only if you also enabled hyperz
manually.
That said, if performance jumps a lot higher with lower texture settings, this
looks like a problem with bo placement/migration, the old code was simple and
terrible in some cases (could easily get texture thrashing) whereas the new
code is different (but still not smart enough). In any case, if you don't have
libtxc installed try that as openarena can use it and hence textures will use
much less vram. If you have some compositing manager running try disabling it
as it will also use more memory. Though if you have some terribly
memory-constrained chip nothing might help much (should really have at least
64MB vram).
As for the ums problem, it looks like the driver is hitting a software
fallback. RADEON_DEBUG=fall might tell you why - not that there's any chance it
will get fixed...
--
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: A question on IOCTL interface for MMC
From: J Freyensee @ 2011-10-24 18:28 UTC (permalink / raw)
To: Shashidhar Hiremath; +Cc: Arnd Bergmann, Chris Ball, John Calixto, linux-mmc
In-Reply-To: <CANYdXnoS31GLnbFcwj76SUoyVhcti8Q-4_5fmyRy3DUJGbSRjg@mail.gmail.com>
On 10/24/2011 05:32 AM, Shashidhar Hiremath wrote:
> Hi Arnd,
> As explained in previous mail, the IOCTL is actually an inteface to
> block layer and it is only expecting read/write commands to be sent
> through the interface.The prrof of it can be seen in write_flag
> present in the IOCTL structure which indicates the either the command
> can be read or a write command.
>
> So, can I submit a linux module to the kernel which uses the same
> mmc_ioc_cmd structure and do all the required processing in my module.
>
> To be clear on my requirement:
> it is To test ALL SD/MMC Commands and NOT just the Read/Write Commands.
> or should I extend the mmc_test module present in kernel to support
> testing of individual commands as well ?
I would think the mmc_test module would be a good vehicle to extend to
have it test individual commands.
Of course if there is no documentation or HOWTO use mmc_test module to
test an individual MMC command then the work is kind-of for naught.
> Can I get some suggestions on what approach to take ?
>
>
> On Thu, Oct 20, 2011 at 12:48 PM, Arnd Bergmann<arnd@arndb.de> wrote:
>>
>> On Thursday 20 October 2011 10:39:00 Shashidhar Hiremath wrote:
>>> I am planning to use the existing IOCTL interface for SD/MMC present
>>> in the kernel.
>>> Since, the IOCTL interface expects a read/write flag , and the MMC
>>> IOCTL is actually an interface to block layer I feel without modifying
>>> the block layer for the support of non-read write commands ,I may not
>>> be able to test the non-read/write commands through the IOCTL
>>> interface .
>>> Is there a way of doing this without modifying block layer ?
>>
>> Hi Shashidhar,
>>
>> I think there is actually no problem here at all. The block layer simply
>> passes the ioctl command number and argument to the driver, which can
>> do anything with it.
>>
>> What functionality are you actually looking for?
>>
>> Arnd
>
>
>
> --
> regards,
> Shashidhar Hiremath
> --
> 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
--
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation
^ permalink raw reply
* [PATCH 1/1] Staging: hv: vmbus: Support building the vmbus driver as part of the kernel
From: K. Y. Srinivasan @ 2011-10-24 18:28 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering
Cc: K. Y. Srinivasan, Haiyang Zhang
Modify the way we initialize the vmbus driver so that all the hyper-v drivers
can be linked with the kernel and still ensure that the vmbus driver
is fully initialized before the drivers that depend upon the vmbus
driver attempt to initialize.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/hv/vmbus_drv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 0c048dd..7d3bccb3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -783,4 +783,4 @@ cleanup:
MODULE_LICENSE("GPL");
MODULE_VERSION(HV_DRV_VERSION);
-module_init(hv_acpi_init);
+subsys_initcall(hv_acpi_init);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 7/9] ib_srpt: Convert srp_max_rdma_size into per port configfs attribute
From: Nicholas A. Bellinger @ 2011-10-24 18:27 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-rdma, Roland Dreier, Christoph Hellwig, target-devel,
linux-scsi
In-Reply-To: <CAO+b5-q+SPZNv-c8Qnho3pzj6xqjTEu9cMAJGeCEr6qquHLScw@mail.gmail.com>
On Mon, 2011-10-24 at 18:34 +0200, Bart Van Assche wrote:
> On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> > This patch converts the srp_max_rdma_size module parameter into a per
> > endpoint configfs attribute. This includes adding the necessary bits
> > for show + store attributes w/ min/max bounds checking, and updating
> > srpt_get_ioc() to accept a struct srpt_port parameter.
> >
> > [ ... ]
> >
> > -static void srpt_get_ioc(struct srpt_device *sdev, u32 slot,
> > +static void srpt_get_ioc(struct srpt_port *sport, u32 slot,
> > struct ib_dm_mad *mad)
>
> The SRP spec says that there should be only one value for
> iocp->rdma_size per I/O controller. This patch breaks that rule. I'm
> not sure it's a good idea to introduce such behavior changes.
>
Hi Bart,
This is something that Roland asked me to persue, so i'll have to defer
to his judgment if he want's to kick this back out to a module parameter
or not.
--nab
^ permalink raw reply
* [Bug 42067] [r600g] Compiz emblem icons corrupted on cayman
From: bugzilla-daemon @ 2011-10-24 18:25 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42067-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42067
--- Comment #3 from Harald Judt <h.judt@gmx.at> 2011-10-24 11:25:31 PDT ---
This was caused by enabling texture compression in core settings. Turning it
off makes the icons look right again.
--
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] mx51evk: Remove unneeded '1' from mx51evk.h
From: Fabio Estevam @ 2011-10-24 18:24 UTC (permalink / raw)
To: u-boot
Remove unneeded '1' from mx51evk.h.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
include/configs/mx51evk.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 2c449b8..af9f983 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -41,12 +41,12 @@
* increase in the final file size: 144260 vs. 109536 Bytes.
*/
-#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */
-#define CONFIG_REVISION_TAG 1
-#define CONFIG_SETUP_MEMORY_TAGS 1
-#define CONFIG_INITRD_TAG 1
+#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
+#define CONFIG_REVISION_TAG
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_INITRD_TAG
-#define CONFIG_OF_LIBFDT 1
+#define CONFIG_OF_LIBFDT
#define CONFIG_MACH_TYPE MACH_TYPE_MX51_BABBAGE
/*
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 6/9] ib_srpt: Remove legacy use_port_guid_in_session_name module parameter
From: Bart Van Assche @ 2011-10-24 18:24 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-rdma, Roland Dreier
In-Reply-To: <1319434422-15354-7-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger
<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org> wrote:
> This patch removes the legacy use_port_guid_in_session_name module parameter
> that is no longer required in modern ib_srpt code.
The patch looks fine to me but the description could be improved: the
"use_port_guid_in_session_name" had been introduced in the past to
work around a limitation of the Windows SRP initiator in multipath
setups. Apparently with recent Windows SRP initiator versions setting
that parameter is no longer necessary.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 42160] [NV4e] Mouse pointer disappears randomly after resuming from GNOME screensaver
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-24 18:22 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-42160-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42160
Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #52688|text/x-log |text/plain
mime type| |
--
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
* [Bug 42160] [NV4e] Mouse pointer disappears randomly after resuming from GNOME screensaver
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-24 18:22 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-42160-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42160
Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #52687|application/octet-stream |text/plain
mime type| |
--
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
* [Bug 42160] [NV4e] Mouse pointer disappears randomly after resuming from GNOME screensaver
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-24 18:22 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-42160-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42160
Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #52686|application/octet-stream |text/plain
mime type| |
--
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: Kernel Panic every 2 weeks on ISP server (NULL pointer dereference)
From: Eric Dumazet @ 2011-10-24 18:21 UTC (permalink / raw)
To: Luciano Ruete; +Cc: netdev
In-Reply-To: <201110241509.14027.lruete@sequre.com.ar>
Le lundi 24 octobre 2011 à 15:09 -0300, Luciano Ruete a écrit :
> Hi Eric!
>
> Thanks for your answer...
>
> >
> > [694250.472081] Code: f6
> > 49 c1 e6 07 shl $0x7,%r14
> > 66 89 93 ac 00 00 00 mov %dx,0xac(%rbx)
> >[...]
> > This looks like a dev_pick_tx() bug, using an out of bound
> > queue_index number and returning a txq pointing after
> > the device allocated array.
>
> Clear explanation, is there a tool to map the trace to kernel code, or you did
> this by hand?
>
In kernek source, you can find scripts/decodecode
# cat CRASH | scripts/decodecode
[694250.472081] Code: f6 49 c1 e6 07 66 89 93 ac 00 00 00 4d 03 b5 40 03 00 00 0f b7 83 a6 00 00 00 4d 8b 66 08 80 e4 cf 80 cc 20 66 89 83 a6 00 00 00 <49> 83 3c 24 00 0f 84 3b 02 00 00 49 8d 84 24 9c 00 00 00 48 89
All code
========
0: f6 (bad)
1: 49 c1 e6 07 shl $0x7,%r14
5: 66 89 93 ac 00 00 00 mov %dx,0xac(%rbx)
c: 4d 03 b5 40 03 00 00 add 0x340(%r13),%r14
13: 0f b7 83 a6 00 00 00 movzwl 0xa6(%rbx),%eax
1a: 4d 8b 66 08 mov 0x8(%r14),%r12
1e: 80 e4 cf and $0xcf,%ah
21: 80 cc 20 or $0x20,%ah
24: 66 89 83 a6 00 00 00 mov %ax,0xa6(%rbx)
2b:* 49 83 3c 24 00 cmpq $0x0,(%r12) <-- trapping instruction
30: 0f 84 3b 02 00 00 je 0x271
36: 49 8d 84 24 9c 00 00 lea 0x9c(%r12),%rax
3d: 00
3e: 48 rex.W
3f: 89 .byte 0x89
Code starting with the faulting instruction
===========================================
0: 49 83 3c 24 00 cmpq $0x0,(%r12)
5: 0f 84 3b 02 00 00 je 0x246
b: 49 8d 84 24 9c 00 00 lea 0x9c(%r12),%rax
12: 00
13: 48 rex.W
14: 89 .byte 0x89
^ permalink raw reply
* Re: [PATCH] mmc: boot partition ro lock support
From: J Freyensee @ 2011-10-24 18:20 UTC (permalink / raw)
To: Chris Ball
Cc: Sebastian Rasmussen, Linus Walleij, Andrei Warkentin, Ulf Hansson,
Per Forlin, Lee Jones, Johan Rudholm, John Beckett, linux-mmc
In-Reply-To: <m2r5245i0y.fsf@bob.laptop.org>
On 10/22/2011 11:38 PM, Chris Ball wrote:
> Hi Sebastian,
>
> On Sat, Oct 22 2011, Sebastian Rasmussen wrote:
>> Hi!
>>
>>> What we're worried about is someone issuing the perm read-only command,
>>> and not realizing that it really means that they can never ever write
>>> any more changes to their eMMC -- it's a one-time fuse
>>
>> I can see why you are worried that people may brick their devices.
>> How about only adding the read-only-until-power-cycled command?
>
> I think that makes sense. I'd be curious to hear if anyone thinks we
> shouldn't even add that command, perhaps on grounds that "the kernel
> shouldn't be enthusiastic about locking itself out of future access to
> a device" or similar. As you say, the ioctl interface would still work.
The only reason why I could think you would want a command like that is
if the kernel goes viral on a normal user on say, a cell phone. Then
this would be more of defensive mechanism that would be tripped.
I think if a hacker/kernel-modifier bricks their device, then that was
their risk, but for a normal user (which makes up the majority of
Android phones in which Android is the majority smart phones out there),
it should be hard to brick a device.
Jay
>
>>> I'd rather leave it to specialized manufacturing equipment.
>>
>> Sure, but then again permanent read-only commands seem to be
>> able to be sent by writing a userspace tool that issues a ioctl(fd, 0xb3, ...)
>> using the generic command interface by John Calixto mentioned by
>> Andrei. I assume that what reassures you in this case is
>> that CAP_SYS_RAWIO is required and perhaps also obscurity?
>
> Yes, that's right -- running a userspace program that you explicitly
> downloaded from somewhere and compiled is more intentional than
> wondering what a kernel argument or sysfs node does and trying it.
> (Maybe I'm special, but I often use kernel arguments and sysfs nodes
> without reading their code or finding the best documentation for them
> first, when trying to get something to work.)
>
> Thanks,
>
> - Chris.
--
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation
^ permalink raw reply
* [Qemu-devel] Windows 98 installer
From: Michael Karcher @ 2011-10-24 18:21 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 6123 bytes --]
Hello developers,
there are plenty of reports in the internet that the Windows 98
installer crashes or hangs in qemu. I took the effort to track down what
causes these problems, and I think I found out the core reason, which
seems to be a bug in the Microsoft DOS Extender DOSX.
The Windows 95/Windows 98 installers are Windows 3.1 applications, and
the setup media contain the Windows 3.1 kernel for "standard mode", i.e.
the 286 mode of Windows 3.1. The lowest layer of Windows 3.1 running in
standard mode is the Microsoft DOS extender, which amongst other things
provides a DPMI host implementation and does interrupt management. The
crashes of the Windows 98 installer I could observe were caused by
overflowing the number of interrupt stacks inside DOSX, which can happen
if interrupts are generated faster than they are handled.
The code path is like this:
While DOSX is active and executing real-mode code with interrupts
enabled, an interrupt occurs (e.g. the timer interrupt). All real mode
interrupt handlers are hooked by dosx, so control is transferred to the
corresponding interrupt handler in dosx. The handler for interrupts
occurring in real mode reflects the interrupt to protected mode. The
reflection to protected mode happens on one of the internal interrupts
stacks inside DOSX. After setting up the interrupt stack and looking up
the protected mode handler, an interrupt return frame for the protected
mode handler is set up containing the flag register value that was
active when the real-mode handler in DOSX was entered (i.e. the return
flags from the DOSX handler are copied to the interrupt stack).
The protected mode interrupt handler in SYSTEM.DRV then at some time
decides to chain to the original protected mode interrupt handler inside
DOSX, either by jumping to the handler re-using the return frame (and
thus the return flags the DOSX handler will see are the same as the code
that reflected the interrupt to protected mode had seen), or on another
code path that has the same net effect [skipped as it does not matter
for the issue here].
So now DOSX is entered again. The default protected mode interrupt
handler then decides to reflect the interrupt to real mode - to all the
code that hooked the interrupt before DOSX was called. Just as for the
reflect-to-protected-mode code, also the reflect-to-real-mode code
allocates an interrupt stack from the stacks inside DOSX, switches to
that stack, and finally calls the original handler (this time in real
mode), with the return frame having the same flags as the return frame
of the reflection handler.
Long story short: So the flags from when the hardware interrupt handler
was entered were passed along into the return frame the reflecting
handler builds for the protected mode handler. The flags from this
return frame are then passed into the return frame of the second
reflecting handler builds for the real mode handler. As interrupts were
enabled at the start of that chain (otherwise, it would not have
started), we know that the interrupt flag is set in the return frame of
the real-mode handler. Also, note that two interrupt stacks got
allocated during this process. (the total number of interrupt stacks is
12 by default, which is not overwritten in the system.ini provided with
the Windows 98 installer)
Now let's assume for some reason the real-mode handler of the timer
interrupt takes more than 55ms to execute (or execution is scheduled
from qemu to another process so that not 55ms of real CPU time is
available between two timer ticks), then the next timer tick is pending
as soon as the real-mode handler of the timer interrupt returns into the
reflect-to-real-mode handler (which is going switch back to protected
mode and return to either SYSTEM.DRV or the reflect-to-protected mode
handler and freeing the interrupt stack used for reflection to real
mode). BUT as we know, the interrupt flag is set in the interrupt return
frame for the real-mode handler - which causes qemu to accept the next
timer interrupt directly after the real mode handler returned, with two
interrupt stacks still allocated.
If the nesting level gets to six, all interrupt stack frames are used.
DOSX still allocates further stack frames, resulting in the stack
pointer pointing into the data segment of DOSX, damaging important data
structures, which will crash the system some time later.
If you know the 8086 architecture by heart, and also know the qemu code,
you could get the idea that there might be an emulation bug causing the
premature acceptance of the second interrupt (would it be accepted after
cleaning up the stack frames, there would be no problem), namely that
after an IRET or STI instruction, interrupts are only accepted after one
further instruction - and only if they are still enabled. So *if* the
real-mode handler returned to an CLI instruction, a real 8086 compatible
CPU would not accept an interrupt between the IRET and CLI. Indeed, the
DOSX code contains an CLI instruction in the code that tears down the
allocated interrupt stack after the real mode handler returned, but it
is not the first, but the third instruction - which is too late even on
real hardware. Tp be exact, the code at the return point of the real
mode handler inside DOSX is "pop ds / pushf / cli".
I don't have any solution for that problem at hand, and I can't say for
sure that this nesting of timer interrupts really is a problem if you
don't trace qemu with "-d in_asm,cpu" (not tracing should make it
faster), but the kind of crashes I saw with and without tracing were
similar, so I expect interrupt stack overflow to cause the crashes
observed in the Windows 98 installer.
The main reason I am writing this mail is to archive the knowledge about
what happens inside the installer, so this tedious tracing process
doesn't have to be reproduced by somebody else interested in fixing the
problem, but I am happy to hear suggestions on how this problem can be
fixed or worked around.
Regards,
Michael Karcher
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RESEND][PATCH 1/1] ipr: add definitions for additional adapter
From: Brian King @ 2011-10-24 18:20 UTC (permalink / raw)
To: Wayne Boyer
Cc: James E.J. Bottomley, Kleber Sacilotto de Souza, Wendy Xiong,
linux-scsi
In-Reply-To: <4EA04B8E.9030909@linux.vnet.ibm.com>
On 10/20/2011 11:25 AM, Wayne Boyer wrote:
> Add the appropriate definitions and table entry for an additional adapter.
>
> Signed-off-by: Wayne Boyer <wayneb@linux.vnet.ibm.com>
Acked-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool.
From: Konrad Rzeszutek Wilk @ 2011-10-24 18:18 UTC (permalink / raw)
To: Thomas Hellstrom
Cc: linux-kernel, dri-devel, thellstrom, airlied, xen-devel, j.glisse,
bskeggs
In-Reply-To: <4EA5A381.1050100@shipmail.org>
> >For that there are couple of architectural issues I am not sure how to solve.
> >
> >There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> >to say: "here is a 'struct page *', give me the bus address". Currently
> >this is solved by keeping an array of DMA addresses along with the list
> >of pages. And passing the list and DMA address up the stack (and down)
> >from TTM up to the driver (when ttm->be->func->populate is called and they
> >are handed off) does it. It does not break any API layering .. and the internal
> >TTM pool (non-DMA) can just ignore the dma_address altogether (see patch above).
> >
>
> I actually had something more simple in mind, but when tinking a bit
> deeper into it, it seems more complicated than I initially thought.
>
> Namely that when we allocate pages from the ttm_backend, we actually
> populated it at the same time. be::populate would then not take a
> page array as an argument, and would actually be a no-op on many
> drivers.
The programming of the gfx's MMU.. would be done via a new API call?
I think this needs a bit of whiteboarding for me to be sure I understand you.
>
> This makes us move towards struct ttm_tt consisting almost only of
> its backend, so that whole API should perhaps be looked at with new
> eyes.
>
> So anyway, I'm fine with high level things as they are now, and the
Great!
> dma_addr issue can be looked at at a later time. If we could get a
> couple of extra eyes to review the code for style etc. would be
Anybody in particular you can recommend that I can pester^H^H^H^H politely
ask :-)
> great, because I have very little time the next couple of weeks.
<nods> Understood.
^ permalink raw reply
* Re: [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool.
From: Konrad Rzeszutek Wilk @ 2011-10-24 18:18 UTC (permalink / raw)
To: Thomas Hellstrom
Cc: thellstrom, xen-devel, linux-kernel, dri-devel, j.glisse, airlied,
bskeggs
In-Reply-To: <4EA5A381.1050100@shipmail.org>
> >For that there are couple of architectural issues I am not sure how to solve.
> >
> >There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> >to say: "here is a 'struct page *', give me the bus address". Currently
> >this is solved by keeping an array of DMA addresses along with the list
> >of pages. And passing the list and DMA address up the stack (and down)
> >from TTM up to the driver (when ttm->be->func->populate is called and they
> >are handed off) does it. It does not break any API layering .. and the internal
> >TTM pool (non-DMA) can just ignore the dma_address altogether (see patch above).
> >
>
> I actually had something more simple in mind, but when tinking a bit
> deeper into it, it seems more complicated than I initially thought.
>
> Namely that when we allocate pages from the ttm_backend, we actually
> populated it at the same time. be::populate would then not take a
> page array as an argument, and would actually be a no-op on many
> drivers.
The programming of the gfx's MMU.. would be done via a new API call?
I think this needs a bit of whiteboarding for me to be sure I understand you.
>
> This makes us move towards struct ttm_tt consisting almost only of
> its backend, so that whole API should perhaps be looked at with new
> eyes.
>
> So anyway, I'm fine with high level things as they are now, and the
Great!
> dma_addr issue can be looked at at a later time. If we could get a
> couple of extra eyes to review the code for style etc. would be
Anybody in particular you can recommend that I can pester^H^H^H^H politely
ask :-)
> great, because I have very little time the next couple of weeks.
<nods> Understood.
^ 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.