Hi
3.2.0-rc3-00015-gaaa0b4f
dmesg |egrep "drm|radeon"
Command line: root=/dev/sda2 radeon.modeset=1 ro
Kernel command line: root=/dev/sda2 radeon.modeset=1 ro
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
radeon :01:00.0: PCI INT A -> GSI 16 (level, low) -> IR
On Mon, Dec 05, 2011 at 11:04:09PM +0100, Arnd Bergmann wrote:
> On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
> > On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> > > ...
> >
> > Thanks a lot for this excellent overview. I think at least for the first
> > version of dmab
On Mon, Dec 05, 2011 at 04:11:46PM -0600, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
> > On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
> >> I sort of preferred having the DMABUF shim because that lets you pass
> >> a buffer around userspace without the rec
On Mon, Dec 05, 2011 at 09:37:15AM -0500, Adam Jackson wrote:
> On Sat, 2011-12-03 at 19:35 +0200, Kirill A. Shutemov wrote:
> > Hi,
> >
> > Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see
> > nothing on the panel after mode setting. Reverting the commit fixes the
> >
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> > On Friday 02 December 2011, Sumit Semwal wrote:
> >> This is the first step in defining a dma buffer sharing mechanism.
> >
> > This looks very nice, but there are a few things I don't
On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
> On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> > ...
>
> Thanks a lot for this excellent overview. I think at least for the first
> version of dmabuf we should drop the sync_* interfaces and simply require
> users to brac
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> > In the patch 2, you have a section about migration that mentions that
> > it is possible to export a buffer that can be migrated after it
> > is already mapped into one user drive
On Mon, Dec 5, 2011 at 9:27 PM, Markus Trippelsdorf
wrote:
>> > Yes the patch finally fixes the issue for me (tested with 120 kexec
>> > iterations).
>> > Thanks Jerome!
>>
>> Can you do a kick run on the modified patch ?
>
> This one is also OK after ~60 iterations.
Jerome, could you please incl
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
> > > The only way to solve this that I can think of right now is to
> > > mandate that the mappings are all coherent (i.e. noncachable
> > > on noncoherent architectures like A
CC-ing intel-gfx at lists.freedesktop.org (see below)
On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote:
> Add Cc. to platform-driver-x86 and linux-acpi
>
> Hi Baptiste
>
> ? ??2011-12-04 ? 17:07 +0100?Baptiste Jonglez ???
> > Hi,
> >
> > I've got a lot of troubles with a dual-LVDS Acer la
https://bugs.freedesktop.org/show_bug.cgi?id=43538
Arkadiusz Miskiewicz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
> > The only way to solve this that I can think of right now is to
> > mandate that the mappings are all coherent (i.e. noncachable
> > on noncoherent architectures like ARM). If you do that, you no
> > longer need the sync_sg_for_* calls.
>
On 2011.12.05 at 14:11 -0500, Jerome Glisse wrote:
> On Mon, Dec 05, 2011 at 07:15:49PM +0100, Markus Trippelsdorf wrote:
> > On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
> > > On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> > > > On 2011.12.03 at 14:31 -0500, Jerome Gl
https://bugs.freedesktop.org/show_bug.cgi?id=43538
Bug #: 43538
Summary: libdrm-2.4.28: rbo.h is missing.
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
On Mon, Dec 05, 2011 at 05:18:48PM +, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
> > + /* allow allocator to take care of cache ops */
> > + void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
> > + void (*sync_sg_for_device)(struct dma_buf *, struct d
From: Rob Clark
TILER/DMM provides two features for omapdrm GEM objects:
1) providing a physically contiguous view to discontiguous memory
for hw initiators that cannot otherwise support discontiguous
buffers (DSS scanout, IVAHD video decode/encode, etc)
2) providing untiling for 2d tiled b
From: Andy Gross
Dynamic Memory Manager (DMM) is a hardware block in the OMAP4+
processor that contains at least one TILER instance. TILER, or
Tiling and Isometric Lightweight Engine for Rotation, provides
IOMMU capabilities through the use of a physical address translation
table. The TILER als
From: Rob Clark
Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC
provides support for remapping physically discontiguous buffers for
various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
non-physically contiguous buffers, as well as providing support for
til
On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
> On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> > On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
> > > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
> > > wrote:
> > > > On 2011.12.03 at 12:20 +, Dave Airlie
From: Jerome Glisse
This allow to share the ib pool with semaphore and avoid
having more bo around.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 67 -
drivers/gpu/drm/radeon/radeon_device.c|2 +-
drivers/gpu/drm/radeon/radeon_ring.c |
From: Jerome Glisse
This avoid to waste ib pool size and avoid a bunch of wait for
previous ib to finish.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/r600_blit_kms.c | 16 +
Two following patch are on top of
http://cgit.freedesktop.org/~glisse/linux
They make the ib allocation size a function of the cs size, this
allow to avoid wasting pool space and avoid to trigger fence_wait
in ib_get. I am still evaluating how much fence_wait we avoid
with this.
Cheers,
Jerome
From: Rob Clark
TILER/DMM provides two features for omapdrm GEM objects:
1) providing a physically contiguous view to discontiguous memory
for hw initiators that cannot otherwise support discontiguous
buffers (DSS scanout, IVAHD video decode/encode, etc)
2) providing untiling for 2d tiled b
From: Rob Clark
Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC
provides support for remapping physically discontiguous buffers for
various DMA initiators (DSS, IVAHD, etc) which do not otherwise support
non-physically contiguous buffers, as well as providing support for
til
On Friday 02 December 2011, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have about things I spotted.
Do you have prototype exporter and consumer d
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann wrote:
> On Monday 05 December 2011 14:46:47 Rob Clark wrote:
>> I sort of preferred having the DMABUF shim because that lets you pass
>> a buffer around userspace without the receiving code knowing about a
>> device specific API. ?But the problem I ev
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann wrote:
>>
>> https://github.com/robclark/kernel-omap4/commits/dmabuf
>
> Ok, thanks. I think it would be good to post these for reference
> in v3, with a clear indication that they are not being submitted
> for discussion/inclusion yet.
btw, don't loo
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
> On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
>> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
>> > In the patch 2, you have a section about migration that mentions that
>> > it is possible to export a buffer that can be
From: Jerome Glisse
This allow to share the ib pool with semaphore and avoid
having more bo around.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 67 -
drivers/gpu/drm/radeon/radeon_device.c|2 +-
drivers/gpu/drm/radeon/radeon_ring.c |
From: Jerome Glisse
This avoid to waste ib pool size and avoid a bunch of wait for
previous ib to finish.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/r600_blit_kms.c | 16 +
Two following patch are on top of
http://cgit.freedesktop.org/~glisse/linux
They make the ib allocation size a function of the cs size, this
allow to avoid wasting pool space and avoid to trigger fence_wait
in ib_get. I am still evaluating how much fence_wait we avoid
with this.
Cheers,
Jerome
_
On Mon, Dec 05, 2011 at 10:10:34PM +0200, Pekka Enberg wrote:
> On Mon, Dec 5, 2011 at 9:27 PM, Markus Trippelsdorf
> wrote:
> >> > Yes the patch finally fixes the issue for me (tested with 120 kexec
> >> > iterations).
> >> > Thanks Jerome!
> >>
> >> Can you do a kick run on the modified patch ?
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>>
>> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>> [2]: http://lwn.net
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>
> This looks very nice, but there are a few things I don't understand yet
> and a bunch of trivial comments I have about t
On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris
Wilson) wrote:
> configure.ac |2 +-
> intel/intel_bufmgr_gem.c | 27 +--
> 2 files changed, 22 insertions(+), 7 deletions(-)
>
> New commits:
> commit e73161a02b604742e3da3bca
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann wrote:
> On Monday 05 December 2011 14:46:47 Rob Clark wrote:
>> I sort of preferred having the DMABUF shim because that lets you pass
>> a buffer around userspace without the receiving code knowing about a
>> device specific API. But the problem I ev
On Mon, Dec 05, 2011 at 11:04:09PM +0100, Arnd Bergmann wrote:
> On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
> > On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> > > ...
> >
> > Thanks a lot for this excellent overview. I think at least for the first
> > version of dmab
On Mon, Dec 05, 2011 at 04:11:46PM -0600, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
> > On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
> >> I sort of preferred having the DMABUF shim because that lets you pass
> >> a buffer around userspace without the rec
application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111205/90a95661/attachment-0001.pgp>
-- next part --
--
All
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann wrote:
>>
>> https://github.com/robclark/kernel-omap4/commits/dmabuf
>
> Ok, thanks. I think it would be good to post these for reference
> in v3, with a clear indication that they are not being submitted
> for discussion/inclusion yet.
btw, don't loo
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
> On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
>> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
>> > In the patch 2, you have a section about migration that mentions that
>> > it is possible to export a buffer that can be
On Mon, Dec 05, 2011 at 07:15:49PM +0100, Markus Trippelsdorf wrote:
> On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
> > On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> > > On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
> > > > On Sat, Dec 3, 2011 at 7:29 AM, Markus
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> > On Friday 02 December 2011, Sumit Semwal wrote:
> >> This is the first step in defining a dma buffer sharing mechanism.
> >
> > This looks very nice, but there are a few things I don't
On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
> On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> > ...
>
> Thanks a lot for this excellent overview. I think at least for the first
> version of dmabuf we should drop the sync_* interfaces and simply require
> users to brac
On Mon, Dec 5, 2011 at 1:15 PM, Markus Trippelsdorf
wrote:
> On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
>> On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
>> > On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
>> > > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
https://bugs.freedesktop.org/show_bug.cgi?id=43538
Arkadiusz Miskiewicz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> > In the patch 2, you have a section about migration that mentions that
> > it is possible to export a buffer that can be migrated after it
> > is already mapped into one user drive
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
> > > The only way to solve this that I can think of right now is to
> > > mandate that the mappings are all coherent (i.e. noncachable
> > > on noncoherent architectures like A
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>
> This looks very nice, but there are a few things I don't understand yet
> and a bunch of trivial comments I have about t
On Mon, Dec 05, 2011 at 10:10:34PM +0200, Pekka Enberg wrote:
> On Mon, Dec 5, 2011 at 9:27 PM, Markus Trippelsdorf
> wrote:
> >> > Yes the patch finally fixes the issue for me (tested with 120 kexec
> >> > iterations).
> >> > Thanks Jerome!
> >>
> >> Can you do a kick run on the modified patch ?
https://bugs.freedesktop.org/show_bug.cgi?id=43538
Bug #: 43538
Summary: libdrm-2.4.28: rbo.h is missing.
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
On Mon, Dec 5, 2011 at 9:27 PM, Markus Trippelsdorf
wrote:
>> > Yes the patch finally fixes the issue for me (tested with 120 kexec
>> > iterations).
>> > Thanks Jerome!
>>
>> Can you do a kick run on the modified patch ?
>
> This one is also OK after ~60 iterations.
Jerome, could you please incl
On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
> > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
> > wrote:
> > > On 2011.12.03 at 12:20 +, Dave Airlie wrote:
> > >> >> > > > > FIX idr_layer_cache: Marking all obj
Given how kexec works we need to disable any kind of GPU writeback
early in GPU initialization just in case some are still active from
previous setup.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++
drivers/gpu/drm/radeon/ni.c|9 +++
drivers/gpu
Given how kexec works we need to disable any kind of GPU writeback
early in GPU initialization just in case some are still active from
previous setup.
v2 follow previous sanity work done on earlier radeon, also write
reg uncondionaly and disable irq too.
Signed-off-by: Jerome Glisse
---
drivers
Given how kexec works we need to disable any kind of GPU writeback
early in GPU initialization just in case some are still active from
previous setup. This patch is done to fix the issue described in
the lkml thread :
WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
https://lkml.org/lkml/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111205/502c2354/attachment.pgp>
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
> > The only way to solve this that I can think of right now is to
> > mandate that the mappings are all coherent (i.e. noncachable
> > on noncoherent architectures like ARM). If you do that, you no
> > longer need the sync_sg_for_* calls.
>
On 2011.12.05 at 14:11 -0500, Jerome Glisse wrote:
> On Mon, Dec 05, 2011 at 07:15:49PM +0100, Markus Trippelsdorf wrote:
> > On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
> > > On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> > > > On 2011.12.03 at 14:31 -0500, Jerome Gl
On Wed, Nov 16, 2011 at 05:17:12PM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2011 at 17:10, James Simmons
> wrote:
> >> > Should I test this set of patches for the VIA driver or wait until you
> >> > have a second version of this patch?
> >>
> >> Testing this on via would be awesome! Iirc I h
On Mon, Dec 05, 2011 at 07:15:49PM +0100, Markus Trippelsdorf wrote:
> On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
> > On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> > > On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
> > > > On Sat, Dec 3, 2011 at 7:29 AM, Markus
Add Cc. to platform-driver-x86 and linux-acpi
Hi Baptiste
? ??2011-12-04 ? 17:07 +0100?Baptiste Jonglez ???
> Hi,
>
> I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't
> have a keyboard, but two displays with touchscreens)
>
> The Intel GPU is integrated into the Core i5-480M
On Mon, Dec 05, 2011 at 05:18:48PM +, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
> > + /* allow allocator to take care of cache ops */
> > + void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
> > + void (*sync_sg_for_device)(struct dma_buf *, struct d
> > If I had to guess it looks like 0 is getting written back to some
> > random page by the GPU maybe, it could be that the GPU is in some
half
> > setup state at boot or on a reboot does it happen from a cold boot
or
> > just warm boot or kexec?
>
> Only happened with kexec thus far. Cold boot
On Mon, Dec 5, 2011 at 1:15 PM, Markus Trippelsdorf
wrote:
> On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
>> On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
>> > On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
>> > > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
On 2011.12.05 at 12:10 -0500, Jerome Glisse wrote:
> On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> > On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
> > > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
> > > wrote:
> > > > On 2011.12.03 at 12:20 +, Dave Airlie
rg/archives/dri-devel/attachments/20111205/7e441c0f/attachment.pgp>
On Friday 02 December 2011, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have about things I spotted.
Do you have prototype exporter and consumer d
On Sun, Dec 04, 2011 at 02:02:00AM +0100, Markus Trippelsdorf wrote:
> On 2011.12.03 at 14:31 -0500, Jerome Glisse wrote:
> > On Sat, Dec 3, 2011 at 7:29 AM, Markus Trippelsdorf
> > wrote:
> > > On 2011.12.03 at 12:20 +, Dave Airlie wrote:
> > >> >> > > > > FIX idr_layer_cache: Marking all obj
On Sat, 2011-12-03 at 19:35 +0200, Kirill A. Shutemov wrote:
> Hi,
>
> Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see
> nothing on the panel after mode setting. Reverting the commit fixes the issue.
Try this patch (might need rediffing):
http://www.mail-archive.com/
> > If I had to guess it looks like 0 is getting written back to some
> > random page by the GPU maybe, it could be that the GPU is in some
half
> > setup state at boot or on a reboot does it happen from a cold boot
or
> > just warm boot or kexec?
>
> Only happened with kexec thus far. Cold boot
xf86-video-intel depends upon a couple of bug fixes in libdrm, hence the
version bump.
-Chris
Chris Wilson (2):
intel: Unmap buffers during drm_intel_gem_bo_unmap
configure: Bump version to 2.4.28
Daniel Vetter (1):
intel: limit aperture space to mappable area on gen3
Jeremy Hu
On Wed, Nov 16, 2011 at 05:17:12PM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2011 at 17:10, James Simmons wrote:
> >> > Should I test this set of patches for the VIA driver or wait until you
> >> > have a second version of this patch?
> >>
> >> Testing this on via would be awesome! Iirc I have
Reviewed-by: Jakob Bornecrantz
- Original Message -
> The advantage of kcalloc is, that will prevent integer overflows
> which could result from the multiplication of number of elements
> and size and it is also a bit nicer to read.
>
> The semantic patch that makes this change is availa
Reviewed-by: Jakob Bornecrantz
- Original Message -
> The advantage of kcalloc is, that will prevent integer overflows
> which could result from the multiplication of number of elements
> and size and it is also a bit nicer to read.
>
> The semantic patch that makes this change is availa
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>>
>> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>> [2]: http://lwn.net
76 matches
Mail list logo
