Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Fri, Mar 10, 2017 at 7:40 AM, Daniel Vetter wrote: > On Fri, Mar 10, 2017 at 10:31:13AM +, Brian Starkey wrote: >> Hi, >> >> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote: >> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >> >> [snip] >> >> > > >> > > For me those patches are going in the right direction. >> > > >> > > I still have few questions: >> > > - since alignment management has been remove from ion-core, should it >> > > be also removed from ioctl structure ? >> > >> > Yes, I think I'm going to go with the suggestion to fixup the ABI >> > so we don't need the compat layer and as part of that I'm also >> > dropping the align argument. >> > >> >> Is the only motivation for removing the alignment parameter that >> no-one got around to using it for something useful yet? >> The original comment was true - different devices do have different >> alignment requirements. >> >> Better alignment can help SMMUs use larger blocks when mapping, >> reducing TLB pressure and the chance of a page table walk causing >> display underruns. > > Extending ioctl uapi is easy, trying to get rid of bad uapi is much > harder. Given that right now we don't have an ion allocator that does > alignment I think removing it makes sense. And if we go with lots of > heaps, we might as well have an ion heap per alignment that your hw needs, > so there's different ways to implement this in the future. slight correction: if you plan ahead (and do things like zero init if userspace passes in a smaller ioctl struct like drm_ioctl does), extending ioctl uapi is easy.. might be something worth fixing from the get-go.. BR, -R > At least from the unix device memory allocator pov it's probably simpler > to encode stuff like this into the heap name, instead of having to pass > heap + list of additional properties/constraints. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On Mon, Mar 13, 2017 at 5:09 PM, Laura Abbott wrote: >> Hm, we might want to expose all the heaps as individual >> /dev/ion_$heapname nodes? Should we do this from the start, since >> we're massively revamping the uapi anyway (imo not needed, current >> state seems to work too)? >> -Daniel >> > > I thought about that. One advantage with separate /dev/ion_$heap > is that we don't have to worry about a limit of 32 possible > heaps per system (32-bit heap id allocation field). But dealing > with an ioctl seems easier than names. Userspace might be less > likely to hardcode random id numbers vs. names as well. other advantage, I think, is selinux (brought up elsewhere on this thread).. heaps at known fixed PAs are useful for certain sorts of attacks so being able to restrict access more easily seems like a good thing BR, -R ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings
On Thu, Feb 27, 2014 at 8:00 AM, Russell King - ARM Linux wrote: > On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote: >> For the i.MX6 display subsystem there is no clear single master device, >> and the physical configuration changes across the SoC family. The >> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and >> IPU2, with two output ports each. > > Not also forgetting that there's another scenario too: you may wish > to drive IPU1 and IPU2 as two completely separate display subsystems > in some hardware, but as a combined display subsystem in others. > > Here's another scenario. You may have these two IPUs on the SoC, but > there's only one display output. You want to leave the second IPU > disabled, as you wouldn't want it to be probed or even exposed to > userland. I agree with Russell here, purely hw description is not always going to be enough information to know how to assemble a bag of parts into a system. Maybe there is some way we should be splitting this "meta" description into different dt files or something like this (?) to make it easier for alternative configurations, but if the hw description alone is not enough information for the drivers to know what to do, some (for lack of a better word) "use-case" configuration is needed, and that has to go *somewhere*... better to put it in DT than hard code it in the driver. BR, -R > On the face of it, the top-level super-device node doesn't look very > hardware-y, but it actually is - it's about how a board uses the > hardware provided. This is entirely in keeping with the spirit of DT, > which is to describe what hardware is present and how it's connected > together, whether it be at the chip or board level. > > If this wasn't the case, we wouldn't even attempt to describe what devices > we have on which I2C buses - we'd just list the hardware on the board > without giving any information about how it's wired together. > > This is no different - however, it doesn't have (and shouldn't) be > subsystem specific... but - and this is the challenge we then face - how > do you decide that on one board with a single zImage kernel, with both > DRM and fbdev built-in, whether to use the DRM interfaces or the fbdev > interfaces? We could have both matching the same compatible string, but > we'd also need some way to tell each other that they're not allowed to > bind. > > Before anyone argues against "it isn't hardware-y", stop and think. > What if I design a board with two Epson LCD controllers on board and > put a muxing arrangement on their output. Is that one or two devices? > What if I want them to operate as one combined system? What if I have > two different LCD controllers on a board. How is this any different > from the two independent IPU hardware blocks integrated inside an iMX6 > SoC with a muxing arrangement on their output? > > It's very easy to look at a SoC and make the wrong decision... > > -- > FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly > improving, and getting towards what was expected from it. > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: change IOCTLs opcode after ABI change
On Fri, Mar 11, 2016 at 5:00 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 07:42:43PM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Burn the old opcode to avoid any potential old userspace running the old >> API to get weird errors. Changing the opcodes will make them fail right >> away. >> >> This is just a precaution, there no upstream users of these interfaces >> yet and the only user is Android, but we don't expect anyone trying to >> run android userspace and all it dependencies on top of upstream kernels. >> >> Moreover Android should be converted to use upstream sync_files. >> >> Suggested-by: Rob Clark >> Signed-off-by: Gustavo Padovan >> --- >> drivers/staging/android/uapi/sync.h | 11 +-- >> 1 file changed, 9 insertions(+), 2 deletions(-) > > Where does this belong in this patch series? Before it? After it? In > the middle? Not sure if overkill, but if we wanted to be pedantic about bisectability put all the uabi struct changes plus ioctl # changes into a single patch (with the following patches starting to use the new fields)? Either way, I think the only two people in the world effected by this (ie. who are playing with AOSP on an upstream (plus a few patches) kernel) are Rob Herring and John Stultz. (Adding them to CC so they are aware). BR, -R > Please resend the whole series, gather up all of the reviewed and > signed-off-by markings from everyone involved, and I'll be glad to apply > them. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()
On Thu, Mar 17, 2016 at 5:19 PM, Gustavo Padovan wrote:
> 2016-03-17 Joe Perches :
>
>> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
>> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches wrote:
>> []
>> > > It's a name that seems like it should be a straightforward
>> > > cast of a kernel pointer to a __user pointer like:
>> > >
>> > > static inline void __user *to_user_ptr(void *p)
>> > > {
>> > > return (void __user *)p;
>> > > }
>> > ahh, ok. I guess I was used to using it in the context of ioctl
>> > structs.. in that context u64 -> (void __user *) made more sense.
>> >
>> > Maybe uapi_to_ptr()? (ok, not super-creative.. maybe someone has a
>> > better idea)
>>
>> Maybe u64_to_user_ptr?
>
> That is a good name. If everyone agrees I can resend this patch
> changing it to u64_to_user_ptr. Then should we still keep it on
> kernel.h?
works for me
BR,
-R
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()
On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches wrote: > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote: >> 2016-03-17 Gustavo Padovan : >> > 2016-03-17 Joe Perches : >> > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote: >> > > > >> > > > This function had copies in 3 different files. Unify them in >> > > > kernel.h. >> > > This is only used by gpu/drm. >> > > >> > > I think this is a poor name for a generic function >> > > that would be in kernel.h. >> > > >> > > Isn't there an include file in linux/drm that's >> > > appropriate for this. Maybe drmP.h >> > > >> > > Maybe prefix this function name with drm_ too. >> > No, the next patch adds a user to drivers/staging (which will be moved >> > to drivers/dma-buf) soon. Maybe move to a different header in >> > include/linux/? not sure which one. >> > >> > > >> > > Also, there's this that might conflict: >> > > >> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p) >> > > ptr_to_compat(p) >> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p) >> > > ((unsigned long)(p)) >> > Right, I'll figure out how to replace these two too. >> The powerpc to_user_ptr has a different meaning from the one I'm adding >> in this patch. I propose we just rename powerpc's to_user_ptr to >> __to_user_ptr and leave the rest as is. > > I think that's not a good idea, and you should really check > this concept with the powerpc folk (added to to:s and cc:ed) > > If it were really added, then the function meaning is incorrect. > > This is taking a u64, casting that to (unsigned long/uint_ptr_t), > then converting that to a user pointer. > > Does that naming and use make sense on x86-32 or arm32? > fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64.. Not entirely sure what doesn't make sense about it BR, -R ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()
On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches wrote:
> On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
>> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches wrote:
>> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> > > 2016-03-17 Gustavo Padovan :
>> > > > 2016-03-17 Joe Perches :
>> > > > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
>> > > > > > This function had copies in 3 different files. Unify them in
>> > > > > > kernel.h.
>> > > > > This is only used by gpu/drm.
>> > > > >
>> > > > > I think this is a poor name for a generic function
>> > > > > that would be in kernel.h.
>> > > > >
>> > > > > Isn't there an include file in linux/drm that's
>> > > > > appropriate for this. Maybe drmP.h
>> > > > >
>> > > > > Maybe prefix this function name with drm_ too.
>> > > > No, the next patch adds a user to drivers/staging (which will be moved
>> > > > to drivers/dma-buf) soon. Maybe move to a different header in
>> > > > include/linux/? not sure which one.
>> > > >
>> > > > >
>> > > > >
>> > > > > Also, there's this that might conflict:
>> > > > >
>> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)
>> > > > > ptr_to_compat(p)
>> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)
>> > > > > ((unsigned long)(p))
>> > > > Right, I'll figure out how to replace these two too.
>> > > The powerpc to_user_ptr has a different meaning from the one I'm adding
>> > > in this patch. I propose we just rename powerpc's to_user_ptr to
>> > > __to_user_ptr and leave the rest as is.
>> > I think that's not a good idea, and you should really check
>> > this concept with the powerpc folk (added to to:s and cc:ed)
>> >
>> > If it were really added, then the function meaning is incorrect.
>> >
>> > This is taking a u64, casting that to (unsigned long/uint_ptr_t),
>> > then converting that to a user pointer.
>> >
>> > Does that naming and use make sense on x86-32 or arm32?
>> >
>> fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
>> Not entirely sure what doesn't make sense about it
>
> It's a name that seems like it should be a straightforward
> cast of a kernel pointer to a __user pointer like:
>
> static inline void __user *to_user_ptr(void *p)
> {
> return (void __user *)p;
> }
ahh, ok. I guess I was used to using it in the context of ioctl
structs.. in that context u64 -> (void __user *) made more sense.
Maybe uapi_to_ptr()? (ok, not super-creative.. maybe someone has a better idea)
BR,
-R
> As a static function in a single file, it's not
> great, but OK, fine, it's static.
>
> As a global function in kernel.h, it's misleading.
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v12 1/2] kernel.h: add u64_to_user_ptr()
On Thu, Apr 21, 2016 at 11:38 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clark
> Signed-off-by: Gustavo Padovan
Acked-by: Rob Clark
>
> ---
> v2: add typecheck() (comment from Maarten Lankhorst)
>
> v3: make u64_to_user_ptr() a macro (comment from Joe Perches)
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
> drivers/gpu/drm/i915/i915_drv.h | 5 -
> drivers/gpu/drm/i915/i915_gem.c | 14 +++---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++---
> drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
> include/linux/kernel.h | 7 +++
> 6 files changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 236ada9..afdd55d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -28,11 +28,6 @@
> #define BO_LOCKED 0x4000
> #define BO_PINNED 0x2000
>
> -static inline void __user *to_user_ptr(u64 address)
> -{
> - return (void __user *)(uintptr_t)address;
> -}
> -
> static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
> struct etnaviv_gpu *gpu, size_t nr)
> {
> @@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev,
> void *data,
> cmdbuf->exec_state = args->exec_state;
> cmdbuf->ctx = file->driver_priv;
>
> - ret = copy_from_user(bos, to_user_ptr(args->bos),
> + ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
> args->nr_bos * sizeof(*bos));
> if (ret) {
> ret = -EFAULT;
> goto err_submit_cmds;
> }
>
> - ret = copy_from_user(relocs, to_user_ptr(args->relocs),
> + ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
> args->nr_relocs * sizeof(*relocs));
> if (ret) {
> ret = -EFAULT;
> goto err_submit_cmds;
> }
>
> - ret = copy_from_user(stream, to_user_ptr(args->stream),
> + ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
> args->stream_size);
> if (ret) {
> ret = -EFAULT;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1048093..bb624cc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct
> drm_device *dev)
> return VGACNTRL;
> }
>
> -static inline void __user *to_user_ptr(u64 address)
> -{
> - return (void __user *)(uintptr_t)address;
> -}
> -
> static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
> {
> unsigned long j = msecs_to_jiffies(m);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dabc089..2889716 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> {
> struct drm_device *dev = obj->base.dev;
> void *vaddr = obj->phys_handle->vaddr + args->offset;
> - char __user *user_data = to_user_ptr(args->data_ptr);
> + char __user *user_data = u64_to_user_ptr(args->data_ptr);
> int ret = 0;
>
> /* We manually control the domain here and pretend that it
> @@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
> int needs_clflush = 0;
> struct sg_page_iter sg_iter;
>
> - user_data = to_user_ptr(args->data_ptr);
> + user_data = u64_to_user_ptr(args->data_ptr);
> remain = args->size;
>
> obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
> @@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
> return 0;
>
> if (!access_ok(VERIFY_WRITE,
> - to_user_ptr(args->data_ptr),
> + u64_to_user_ptr(args->data_ptr),
>args->size))
> return -EFAULT;
>
> @@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
> if (ret)
> goto out_unpin;
>
> - user_data = to_user_ptr(args-&
Re: [PATCH] staging/android: add flags member to sync ioctl structs
On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Play safe and add flags member to all structs. So we don't need to >> break API or create new IOCTL in the future if new features that requires >> flags arises. >> >> v2: check if flags are valid (zero, in this case) >> >> v3: return -EINVAL if flags are not zero'ed >> >> v4: add padding for 64-bit alignment >> >> v5: rebase to use only stacked sync_file_info > > Why are these vX things here in the changelog? > > And you just broke all existing userspace users of this code, why are > you allowed to do that? > > not ok... There are not really any users of this on an upstream kernel yet, so it makes sense to fix the ABI to something we can live with now, before that changes. If we are stuck not breaking ABI with android stuff pulled into staging as we destage it, then maybe we should be a *lot* slower at pulling android stuff into staging. (Ie. if that is the case, please kick it all out now and we'll re-add things properly.) BR, -R ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: add flags member to sync ioctl structs
On Thu, Mar 3, 2016 at 3:54 PM, Rob Clark wrote: > On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman > wrote: >> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> Play safe and add flags member to all structs. So we don't need to >>> break API or create new IOCTL in the future if new features that requires >>> flags arises. >>> >>> v2: check if flags are valid (zero, in this case) >>> >>> v3: return -EINVAL if flags are not zero'ed >>> >>> v4: add padding for 64-bit alignment >>> >>> v5: rebase to use only stacked sync_file_info >> >> Why are these vX things here in the changelog? >> >> And you just broke all existing userspace users of this code, why are >> you allowed to do that? >> >> not ok... > > There are not really any users of this on an upstream kernel yet, so > it makes sense to fix the ABI to something we can live with now, > before that changes. If we are stuck not breaking ABI with android > stuff pulled into staging as we destage it, then maybe we should be a > *lot* slower at pulling android stuff into staging. (Ie. if that is > the case, please kick it all out now and we'll re-add things > properly.) That all said, I suppose one sensible concession to practicality would be to burn the old ioctl numbers and pick new ioctl numbers. At least this way if someone did manage to take an old android userspace (with it's various dependencies on other non-upstream SoC specific platform drivers, etc) and run it on upstream kernel, at least things would fail in an obvious way. I could live with this as the mode-of-operations for fixing up and destaging staging/android stuff. BR, -R ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC 0/6] Module for tracking/accounting shared memory buffers
On Tue, Oct 11, 2016 at 7:50 PM, Ruchi Kandoi wrote:
> This patchstack introduces a new "memtrack" module for tracking and accounting
> memory exported to userspace as shared buffers, like dma-buf fds or GEM
> handles.
btw, I wouldn't care much about the non-dmabuf case.. dri2/flink is
kind of legacy and the sharing patterns there are not so complex that
we have found the need for any more elaborate debug infrastructure
than what we already have.
Between existing dmabuf debugfs, and /proc/*/maps (and /proc/*/fd?), I
wonder what is missing? Maybe there is a less intrusive way to get at
the debugging info you want?
BR,
-R
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address space. This problem is especially bad for systems like
> Android that use dma-buf fds to share graphics and multimedia buffers between
> processes: these allocations are often large, have complex sharing patterns,
> and are rarely mapped into every process that holds a reference to them.
>
> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc. memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't
> double-counted.
>
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer. For fd-backed buffers like dma-bufs, hooks
> in
> fdtable.c and fork.c automatically notify memtrack when references are added
> or
> removed from a process's fd table.
>
> This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.
>
> Greg Hackmann (1):
> drivers: staging: ion: add ION_IOC_TAG ioctl
>
> Ruchi Kandoi (5):
> fs: add installed and uninstalled file_operations
> drivers: misc: add memtrack
> dma-buf: add memtrack support
> memtrack: Adds the accounting to keep track of all mmaped/unmapped
> pages.
> memtrack: Add memtrack accounting for forked processes.
>
> drivers/android/binder.c| 4 +-
> drivers/dma-buf/dma-buf.c | 37 +++
> drivers/misc/Kconfig| 16 +
> drivers/misc/Makefile | 1 +
> drivers/misc/memtrack.c | 516
>
> drivers/staging/android/ion/ion-ioctl.c | 17 ++
> drivers/staging/android/ion/ion.c | 60 +++-
> drivers/staging/android/ion/ion_priv.h | 2 +
> drivers/staging/android/uapi/ion.h | 25 ++
> fs/file.c | 38 ++-
> fs/open.c | 2 +-
> fs/proc/base.c | 4 +
> include/linux/dma-buf.h | 5 +
> include/linux/fdtable.h | 4 +-
> include/linux/fs.h | 2 +
> include/linux/memtrack.h| 130
> include/linux/mm.h | 3 +
> include/linux/sched.h | 3 +
> kernel/fork.c | 23 +-
> 19 files changed, 875 insertions(+), 17 deletions(-)
> create mode 100644 drivers/misc/memtrack.c
> create mode 100644 include/linux/memtrack.h
>
> --
> 2.8.0.rc3.226.g39d4020
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] drm: Add LCD display clock polarity flags
On Mon, Dec 2, 2013 at 3:01 PM, Russell King - ARM Linux wrote: > On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote: >> Add DRM flags for the LCD display clock polarity so the pixelclk-active DT >> property can be properly handled by drivers using the DRM API. > > I still say that not even this should be part of the DRM mode API to > userspace. The hint that you're changing the user API is that you're > modifying a header file below a 'uapi' directory. > > The settings of double scan, sync polarity etc are all part of the > display mode specification (check CEA-861 documents). Things like > pixel clock polarity are not part of the mode specification, they're > a property of the display itself and are independent of the mode. > > Therefore, they should not be part of struct drm_mode_modeinfo. Note that we could make them part of drm_display_mode (but drm_crtc_convert_to_umode() should filter them out when copying from drm_mode_modeinfo.. I agree this information should not be coming from userspace). Seems like the sort of thing that the bridge or encoder could set on the adjusted_mode. BR, -R > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
