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 64bi
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 64bi
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 I
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
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 I
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 backin
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 backin
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
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 a
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-u
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 wou
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 a
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-u
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 wou
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
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
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
> clien
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 b
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 t
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 abl
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 acce
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 subm
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 wit
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 thou
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 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 chec
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 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
> clien
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 t
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 b
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 subm
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 abl
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 wit
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 acce
>
> 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
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 check
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 com
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 st
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
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 exyn
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.
> They
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 rea
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 implementing
> 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;
> +
> + INIT_
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 com
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
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 st
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
> > > wrote:
> > >> Thanks for the pointer, I looked at exynos code.
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.
> They
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 implementing
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 rea
>
> 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
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 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 oth
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 ++--
drivers/gpu/drm/tegra/gr2d
> 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;
> +
> + INIT_
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 othe
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 ++--
drivers/gpu/drm/tegra/gr2d
66 matches
Mail list logo
