On 12/03/2012 05:40 PM, Daniel Vetter wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang wrote:
>> I'm new in kernel development. Could you tell me or give me some
>> materials to read that why we need to align the size of IOCTL structures
>> to 64bit? I can understand if we're working in a
Hi Dave:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're working in a 64bit kernel but why we
need to do this if we're in a 32bit arm kernel? Besides, why the
pointers in
On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang wrote:
> I'm new in kernel development. Could you tell me or give me some
> materials to read that why we need to align the size of IOCTL structures
> to 64bit? I can understand if we're working in a 64bit kernel but why we
> need to do this if we're in
Hi Dave:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're working in a 64bit kernel but why we
need to do this if we're in a 32bit arm kernel? Besides, why the
pointers in
On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang nvmarkzh...@gmail.com wrote:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're working in a 64bit kernel but why we
need to do
On 12/03/2012 05:40 PM, Daniel Vetter wrote:
On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang nvmarkzh...@gmail.com wrote:
I'm new in kernel development. Could you tell me or give me some
materials to read that why we need to align the size of IOCTL structures
to 64bit? I can understand if we're
On 29.11.2012 14:14, Thierry Reding wrote:
> On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
>> This way you would also be able to construct different handles (like GEM
>> obj or V4L2 buffers) from the same backing nvhost object. Note that I'm
>> not sure how useful this would be, but
Am Freitag, den 30.11.2012, 09:44 +0200 schrieb Terje Bergstr?m:
> On 29.11.2012 14:14, Thierry Reding wrote:
> > On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
> >> This way you would also be able to construct different handles (like GEM
> >> obj or V4L2 buffers) from the same
On 29.11.2012 14:14, Thierry Reding wrote:
On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
This way you would also be able to construct different handles (like GEM
obj or V4L2 buffers) from the same backing nvhost object. Note that I'm
not sure how useful this would be, but it
Am Freitag, den 30.11.2012, 09:44 +0200 schrieb Terje Bergström:
On 29.11.2012 14:14, Thierry Reding wrote:
On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
This way you would also be able to construct different handles (like GEM
obj or V4L2 buffers) from the same backing nvhost
On 29.11.2012 11:09, Lucas Stach wrote:
> We should aim for a clean split here. GEM handles are something which is
> really specific to how DRM works and as such should be constructed by
> tegradrm. nvhost should really just manage allocations/virtual address
> space and provide something that is
On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergstr?m:
> > On 28.11.2012 20:46, Lucas Stach wrote:
> > > Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
> > >> Sorry. I promised in another thread a
On 28.11.2012 20:46, Lucas Stach wrote:
> Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
>> Sorry. I promised in another thread a write-up explaining the design. I
>> still owe you guys that.
> That would be really nice to have. I'm also particularly interested in
> how you plan
Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 20:46, Lucas Stach wrote:
> > Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
> >> Sorry. I promised in another thread a write-up explaining the design. I
> >> still owe you guys that.
> > That
On 28.11.2012 20:46, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
That would be really nice to have. I'm also particularly interested in
how you plan to do
Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergström:
On 28.11.2012 20:46, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
That would be
On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergström:
On 28.11.2012 20:46, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
Sorry. I promised in another thread a write-up
On 29.11.2012 11:09, Lucas Stach wrote:
We should aim for a clean split here. GEM handles are something which is
really specific to how DRM works and as such should be constructed by
tegradrm. nvhost should really just manage allocations/virtual address
space and provide something that is able
On 11/28/2012 02:33 PM, Lucas Stach wrote:
> Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergstr?m:
>> On 28.11.2012 01:00, Dave Airlie wrote:
>>> We generally aim for the first, to stop the gpu from reading/writing
>>> any memory it hasn't been granted access to,
>>> the second is
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 17:13, Lucas Stach wrote:
> > To be honest I still don't grok all of this, but nonetheless I try my
> > best.
>
> Sorry. I promised in another thread a write-up explaining the design. I
> still owe you guys that.
>
On 28.11.2012 17:13, Lucas Stach wrote:
> To be honest I still don't grok all of this, but nonetheless I try my
> best.
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
> Anyway, shouldn't nvhost be something like an allocator used by host1x
>
On 28.11.2012 16:06, Lucas Stach wrote:
> Why do even need/use dma-buf for this use case? This is all one DRM
> device, even if we separate host1x and gr2d as implementation modules.
I didn't want to implement dependency to drm gem objects in nvhost, but
we have thought about doing that. dma-buf
Am Mittwoch, den 28.11.2012, 16:45 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 16:06, Lucas Stach wrote:
> > Why do even need/use dma-buf for this use case? This is all one DRM
> > device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency
On 28.11.2012 15:33, Lucas Stach wrote:
> So this is obviously wrong. Userspace has to allocate a pushbuffer from
> the kernel just as every other buffer, then map it into it's own address
> space to push in commands. At submit time of the pushbuf kernel has to
> make sure that userspace is not
On 28.11.2012 01:00, Dave Airlie wrote:
> We generally aim for the first, to stop the gpu from reading/writing
> any memory it hasn't been granted access to,
> the second is nice to have though, but really requires a GPU with VM
> to implement properly.
I wonder if we should aim at root only
Am Mittwoch, den 28.11.2012, 15:57 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 15:33, Lucas Stach wrote:
> > So this is obviously wrong. Userspace has to allocate a pushbuffer from
> > the kernel just as every other buffer, then map it into it's own address
> > space to push in commands. At
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 01:00, Dave Airlie wrote:
> > We generally aim for the first, to stop the gpu from reading/writing
> > any memory it hasn't been granted access to,
> > the second is nice to have though, but really requires a GPU
On 11/28/2012 07:45 AM, Terje Bergstr?m wrote:
> On 28.11.2012 16:06, Lucas Stach wrote:
>> Why do even need/use dma-buf for this use case? This is all one DRM
>> device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency to drm gem objects in
On Tue, Nov 27, 2012 at 9:31 PM, Terje Bergstr?m
wrote:
> On 27.11.2012 12:37, Thierry Reding wrote:
>> But in that case it should be made mandatory at first until proper IOMMU
>> support is enabled on Tegra30. Then it can be checked at driver probe
>> time whether or not to enable the extra
On 28.11.2012 01:00, Dave Airlie wrote:
We generally aim for the first, to stop the gpu from reading/writing
any memory it hasn't been granted access to,
the second is nice to have though, but really requires a GPU with VM
to implement properly.
I wonder if we should aim at root only access
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergström:
On 28.11.2012 01:00, Dave Airlie wrote:
We generally aim for the first, to stop the gpu from reading/writing
any memory it hasn't been granted access to,
the second is nice to have though, but really requires a GPU with VM
On 28.11.2012 15:33, Lucas Stach wrote:
So this is obviously wrong. Userspace has to allocate a pushbuffer from
the kernel just as every other buffer, then map it into it's own address
space to push in commands. At submit time of the pushbuf kernel has to
make sure that userspace is not able
Am Mittwoch, den 28.11.2012, 15:57 +0200 schrieb Terje Bergström:
On 28.11.2012 15:33, Lucas Stach wrote:
So this is obviously wrong. Userspace has to allocate a pushbuffer from
the kernel just as every other buffer, then map it into it's own address
space to push in commands. At submit
On 28.11.2012 16:06, Lucas Stach wrote:
Why do even need/use dma-buf for this use case? This is all one DRM
device, even if we separate host1x and gr2d as implementation modules.
I didn't want to implement dependency to drm gem objects in nvhost, but
we have thought about doing that. dma-buf
Am Mittwoch, den 28.11.2012, 16:45 +0200 schrieb Terje Bergström:
On 28.11.2012 16:06, Lucas Stach wrote:
Why do even need/use dma-buf for this use case? This is all one DRM
device, even if we separate host1x and gr2d as implementation modules.
I didn't want to implement dependency to drm
On 28.11.2012 17:13, Lucas Stach wrote:
To be honest I still don't grok all of this, but nonetheless I try my
best.
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
Anyway, shouldn't nvhost be something like an allocator used by host1x
clients?
On 11/28/2012 07:45 AM, Terje Bergström wrote:
On 28.11.2012 16:06, Lucas Stach wrote:
Why do even need/use dma-buf for this use case? This is all one DRM
device, even if we separate host1x and gr2d as implementation modules.
I didn't want to implement dependency to drm gem objects in
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
On 28.11.2012 17:13, Lucas Stach wrote:
To be honest I still don't grok all of this, but nonetheless I try my
best.
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
That
On 11/28/2012 02:33 PM, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergström:
On 28.11.2012 01:00, Dave Airlie wrote:
We generally aim for the first, to stop the gpu from reading/writing
any memory it hasn't been granted access to,
the second is nice to have
>
> Third would be having a firewall in 2D driver checking the stream and
> ensuring all registers that accept addresses are written by values
> derived from dmabufs. I haven't tried implementing this, but it'd
> involve a lookup table in kernel and CPU reading through the command
> stream.
On 27.11.2012 13:47, Lucas Stach wrote:
> I guess we could change IOMMU address spaces for the graphics units
> depending on the active channel. This would still be a bit of a
> performance hit, because of the necessary TLB flushing and so on, but
> should be much better than checking the whole
On 27.11.2012 12:37, Thierry Reding wrote:
> But in that case it should be made mandatory at first until proper IOMMU
> support is enabled on Tegra30. Then it can be checked at driver probe
> time whether or not to enable the extra checks. That way we don't need a
> special Kconfig option and we
Am Dienstag, den 27.11.2012, 13:31 +0200 schrieb Terje Bergstr?m:
> On 27.11.2012 12:37, Thierry Reding wrote:
> > But in that case it should be made mandatory at first until proper IOMMU
> > support is enabled on Tegra30. Then it can be checked at driver probe
> > time whether or not to enable
On Tue, Nov 27, 2012 at 11:22:56AM +0100, Lucas Stach wrote:
> Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergstr?m:
> > On 27.11.2012 10:32, Dave Airlie wrote:
> > > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m > > nvidia.com> wrote:
> > >> Thanks for the pointer, I looked at
Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergstr?m:
> On 27.11.2012 10:32, Dave Airlie wrote:
> > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m
> > wrote:
> >> Thanks for the pointer, I looked at exynos code. It indeed checks the
> >> registers written to, but it doesn't prevent
On 27.11.2012 10:32, Dave Airlie wrote:
> On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m
> wrote:
>> Thanks for the pointer, I looked at exynos code. It indeed checks the
>> registers written to, but it doesn't prevent overrun by checking sizes
>> of buffers and compare against requests.
>
On 27.11.2012 09:33, Dave Airlie wrote:
>> Third would be having a firewall in 2D driver checking the stream and
>> ensuring all registers that accept addresses are written by values
>> derived from dmabufs. I haven't tried implementing this, but it'd
>> involve a lookup table in kernel and CPU
On 27.11.2012 00:15, Dave Airlie wrote:
>> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
>> {
>> - return 0;
>> + struct tegra_drm_fpriv *fpriv;
>> + int err = 0;
>> +
>> + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
>> + if (!fpriv)
>> +
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m
wrote:
> On 27.11.2012 09:33, Dave Airlie wrote:
>>> Third would be having a firewall in 2D driver checking the stream and
>>> ensuring all registers that accept addresses are written by values
>>> derived from dmabufs. I haven't tried
> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
> {
> - return 0;
> + struct tegra_drm_fpriv *fpriv;
> + int err = 0;
> +
> + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
> + if (!fpriv)
> + return -ENOMEM;
> +
> +
On 27.11.2012 09:33, Dave Airlie wrote:
Third would be having a firewall in 2D driver checking the stream and
ensuring all registers that accept addresses are written by values
derived from dmabufs. I haven't tried implementing this, but it'd
involve a lookup table in kernel and CPU reading
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com wrote:
On 27.11.2012 09:33, Dave Airlie wrote:
Third would be having a firewall in 2D driver checking the stream and
ensuring all registers that accept addresses are written by values
derived from dmabufs. I haven't tried
On 27.11.2012 10:32, Dave Airlie wrote:
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com
wrote:
Thanks for the pointer, I looked at exynos code. It indeed checks the
registers written to, but it doesn't prevent overrun by checking sizes
of buffers and compare against
Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergström:
On 27.11.2012 10:32, Dave Airlie wrote:
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com
wrote:
Thanks for the pointer, I looked at exynos code. It indeed checks the
registers written to, but it
On Tue, Nov 27, 2012 at 11:22:56AM +0100, Lucas Stach wrote:
Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergström:
On 27.11.2012 10:32, Dave Airlie wrote:
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström tbergst...@nvidia.com
wrote:
Thanks for the pointer, I looked at
On 27.11.2012 12:37, Thierry Reding wrote:
But in that case it should be made mandatory at first until proper IOMMU
support is enabled on Tegra30. Then it can be checked at driver probe
time whether or not to enable the extra checks. That way we don't need a
special Kconfig option and we still
Am Dienstag, den 27.11.2012, 13:31 +0200 schrieb Terje Bergström:
On 27.11.2012 12:37, Thierry Reding wrote:
But in that case it should be made mandatory at first until proper IOMMU
support is enabled on Tegra30. Then it can be checked at driver probe
time whether or not to enable the extra
On 27.11.2012 13:47, Lucas Stach wrote:
I guess we could change IOMMU address spaces for the graphics units
depending on the active channel. This would still be a bit of a
performance hit, because of the necessary TLB flushing and so on, but
should be much better than checking the whole
On Tue, Nov 27, 2012 at 9:31 PM, Terje Bergström tbergst...@nvidia.com wrote:
On 27.11.2012 12:37, Thierry Reding wrote:
But in that case it should be made mandatory at first until proper IOMMU
support is enabled on Tegra30. Then it can be checked at driver probe
time whether or not to enable
On Mon, Nov 26, 2012 at 7:19 AM, Terje Bergstrom
wrote:
>
> +struct tegra_drm_submit_args {
> + void *context;
Just a quick comment..
You shouldn't really use ptr here, but instead use a 64bit type so
that you don't run into issues later for armv8/64bit. Same comment
applies in a few
Add client driver for 2D device.
Signed-off-by: Arto Merilainen
Signed-off-by: Terje Bergstrom
---
drivers/gpu/drm/tegra/Makefile |2 +-
drivers/gpu/drm/tegra/drm.c| 231 +++-
drivers/gpu/drm/tegra/drm.h| 42 ++--
Add client driver for 2D device.
Signed-off-by: Arto Merilainen amerilai...@nvidia.com
Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
---
drivers/gpu/drm/tegra/Makefile |2 +-
drivers/gpu/drm/tegra/drm.c| 231 +++-
drivers/gpu/drm/tegra/drm.h
On Mon, Nov 26, 2012 at 7:19 AM, Terje Bergstrom tbergst...@nvidia.com wrote:
+struct tegra_drm_submit_args {
+ void *context;
Just a quick comment..
You shouldn't really use ptr here, but instead use a 64bit type so
that you don't run into issues later for armv8/64bit. Same comment
static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
{
- return 0;
+ struct tegra_drm_fpriv *fpriv;
+ int err = 0;
+
+ fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
+ if (!fpriv)
+ return -ENOMEM;
+
+
On 27.11.2012 00:15, Dave Airlie wrote:
static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
{
- return 0;
+ struct tegra_drm_fpriv *fpriv;
+ int err = 0;
+
+ fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
+ if (!fpriv)
+
Third would be having a firewall in 2D driver checking the stream and
ensuring all registers that accept addresses are written by values
derived from dmabufs. I haven't tried implementing this, but it'd
involve a lookup table in kernel and CPU reading through the command
stream. Offsets and
66 matches
Mail list logo
