On Thu 10-12-15 17:48:31, Sebastian Frias wrote:
> On 12/10/2015 03:06 PM, Michal Hocko wrote:
> >On Thu 10-12-15 14:37:38, Sebastian Frias wrote:
> >>On 12/10/2015 12:40 PM, Michal Hocko wrote:
> >>>On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
> >>>[...]
> We've seen that drivers/media/pci
On 12/10/2015 03:06 PM, Michal Hocko wrote:
On Thu 10-12-15 14:37:38, Sebastian Frias wrote:
On 12/10/2015 12:40 PM, Michal Hocko wrote:
On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
[...]
We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
be doing as us kmalloc+rem
On Thu 10-12-15 14:37:38, Sebastian Frias wrote:
> On 12/10/2015 12:40 PM, Michal Hocko wrote:
> >On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
> >[...]
> >>We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
> >>be doing as us kmalloc+remap_pfn_range,
> >
> >This driver
On 12/10/2015 12:40 PM, Michal Hocko wrote:
On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
[...]
We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
be doing as us kmalloc+remap_pfn_range,
This driver is broken - I will post a patch.
Ok, we'll be glad to see a good
On Thu, Dec 10, 2015 at 12:40 PM, Michal Hocko wrote:
> On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
> [...]
>> We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
>> be doing as us kmalloc+remap_pfn_range,
>
> This driver is broken - I will post a patch.
>
>> is there
On Wed 09-12-15 16:35:53, Sebastian Frias wrote:
[...]
> We've seen that drivers/media/pci/zoran/zoran_driver.c for example seems to
> be doing as us kmalloc+remap_pfn_range,
This driver is broken - I will post a patch.
> is there any guarantee (or at least an advised heuristic) to determine
> if
On 12/09/2015 04:12 PM, Michal Hocko wrote:
On Wed 09-12-15 15:53:22, Sebastian Frias wrote:
[...]
2) Now that VM_RESERVED was removed, is there another recommended flag to
replace it for the purposes above?
VM_IO + potentially others depending on your usecase.
3) Since it was working before
On Wed 09-12-15 15:53:22, Sebastian Frias wrote:
[...]
> 2) Now that VM_RESERVED was removed, is there another recommended flag to
> replace it for the purposes above?
VM_IO + potentially others depending on your usecase.
> 3) Since it was working before, we suppose that something that was
> prev
On 12/09/2015 03:32 PM, Michal Hocko wrote:
On Wed 09-12-15 15:07:50, Marc Gonzalez wrote:
On 09/12/2015 14:55, Michal Hocko wrote:
On Tue 08-12-15 18:25:31, Sebastian Frias wrote:
Hi,
We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
The driver maps kmalloc'ed memory
On Wed 09-12-15 15:07:50, Marc Gonzalez wrote:
> On 09/12/2015 14:55, Michal Hocko wrote:
> > On Tue 08-12-15 18:25:31, Sebastian Frias wrote:
> >> Hi,
> >>
> >> We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
> >>
> >> The driver maps kmalloc'ed memory to user space.
> >
On 09/12/2015 14:55, Michal Hocko wrote:
> On Tue 08-12-15 18:25:31, Sebastian Frias wrote:
>> Hi,
>>
>> We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
>>
>> The driver maps kmalloc'ed memory to user space.
>
> This sounds like a terrible idea to me. Why don't you simply
On Tue 08-12-15 18:25:31, Sebastian Frias wrote:
> Hi,
>
> We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
>
> The driver maps kmalloc'ed memory to user space.
This sounds like a terrible idea to me. Why don't you simply use the
page allocator directly? Try to imagine wh
Hi,
We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9.
The driver maps kmalloc'ed memory to user space.
The usermode sees a contiguous space, although in reality it could span
several chunks of memory allocated with separate calls to kmalloc.
For simplicity, the below exam
13 matches
Mail list logo
