Re: [Linux-fbdev-devel] [PATCH v2 2/2] ep93xx video driver

[Ryan M. <ry...@bl...>]

H Hartley Sweeten wrote:
> On Friday, July 17, 2009 1:23 PM, Ryan Mallon wrote:
>   
>> +static int __init ep93xxfb_alloc_videomem(struct fb_info *info)
>> +{
>> +	struct ep93xx_fbi *fbi = info->par;
>> +	char __iomem *virt_addr;
>> +	dma_addr_t phys_addr;
>> +	unsigned int fb_size;
>> +
>> +	fb_size = ep93xxfb_calc_fbsize(fbi->mach_info);
>> +	virt_addr = dma_alloc_writecombine(info->dev, fb_size,
>> +					   &phys_addr, GFP_KERNEL);
>> +	if (!virt_addr)
>> +		return -ENOMEM;
>> +	
>> +	/*
>> +	 * There is a bug in the ep93xx framebuffer which causes problems
>> +	 * if bit 27 of the physical address is set.
>> +	 * See: http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2
>> +	 * There does not seem to be any offical errata for this, but I
>> +	 * have confirmed the problem exists on my hardware (ep9315) at
>> +	 * least.
>> +	 */
>> +	if (check_screenpage_bug && phys_addr & (1 << 27)) {
>> +		dev_err(info->dev, "ep93xx framebuffer bug. phys addr (0x%x) "
>> +			"has bit 27 set: cannot init framebuffer\n", 
>> +			phys_addr);
>> +		
>> +		dma_free_coherent(info->dev, fb_size, virt_addr, phys_addr);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	info->fix.smem_start = phys_addr;
>> +	info->fix.smem_len = fb_size;
>> +	info->screen_base = virt_addr;
>> +
>> +	return 0;
>> +}
>>     
>
> Were you able to test the SROMLL bit?  If that "fixes" the bit 27 bug maybe
> this should be added to the comment.  As far as I can tell, if the SROMLL bit
> is set it is impossbile to have an SDRAM physical address that would have
> bit 27 set.  With it cleared there are a number of memory configurations that
> might have it set.
>
>   
I tried the different memory layout you suggested, but I got a massive
kernel panic in the memory manager near the end of the boot process. I
haven't looked into it too much yet, one of my workmates seemed to think
that the way our SDRAM is wired up means that we can only use the memory
layout we have.

~Ryan