Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: linux-kernel@vger.kernel.org, Helge Deller <deller@gmx.de>,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	linux-mips@vger.kernel.org
Subject: Re: [RFC PATCH] fbdev: maxinefb: fix build issues
Date: Thu, 13 Aug 2026 14:46:38 -0700	[thread overview]
Message-ID: <e4b67f1e-4afa-4d8b-bd28-28e8e991dfa4@infradead.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2608131801340.48788@angie.orcam.me.uk>



On 8/13/26 10:31 AM, Maciej W. Rozycki wrote:
> On Sun, 9 Aug 2026, Randy Dunlap wrote:
> 
>> This is all ancient source code from the beginning of git time.
> 
>  I can dig out any further details you may need from the old LMO git tree.  
> Eventually it's planned to be put back online, but resources.
> 
>> Now builds cleanly on 32-bit and 64-bit MACH_DECSTATION.
> 
>  Thanks for doing this work.
> 
>> Suggested-by: "Maciej W. Rozycki" <macro@orcam.me.uk> # for s/KSEG1ADDR/CKSEG1ADDR/
> 
>  Eventually this code should be converted to a platform device, so such 
> hacks won't be necessary.  Sadly I declined an offer back in 2009 and I 
> have been chasing a specimen for a while now.  And since it's an onboard 
> device unlike all the TURBOchannel framebuffers, there's no alternative.
> 
>> --- linux-next-20260807.orig/drivers/video/fbdev/maxinefb.c
>> +++ linux-next-20260807/drivers/video/fbdev/maxinefb.c
>> @@ -71,19 +71,6 @@ void maxinefb_ims332_write_register(int
>>  	*((volatile unsigned short *) (wptr)) = val;
>>  }
>>  
>> -unsigned int maxinefb_ims332_read_register(int regno)
>> -{
>> -	register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS;
>> -	unsigned char *rptr;
>> -	register unsigned int j, k;
>> -
>> -	rptr = regs + 0x80000 + (regno << 4);
>> -	j = *((volatile unsigned short *) rptr);
>> -	k = *((volatile unsigned short *) regs);
>> -
>> -	return (j & 0xffff) | ((k & 0xff00) << 8);
>> -}
>> -
>>  /* Set the palette */
>>  static int maxinefb_setcolreg(unsigned regno, unsigned red, unsigned green,
>>  			      unsigned blue, unsigned transp, struct fb_info *info)
> 
>  It might be worth mentioning in the change description that this is dead 
> code (and overall provide a summary as to making functions static, etc.).  
> Though I'm not entirely convinced as to the removal since this function 
> documents the hardware interface, which must have been the intent to put 
> it there.  Perhaps #if 0?
> 
>> --- linux-next-20260807.orig/include/video/maxinefb.h
>> +++ linux-next-20260807/include/video/maxinefb.h
>> @@ -13,13 +13,13 @@
>>  /*
>>   * IMS332 video controller register base address
>>   */
>> -#define MAXINEFB_IMS332_ADDRESS		KSEG1ADDR(0x1c140000)
>> +#define MAXINEFB_IMS332_ADDRESS		CKSEG1ADDR(0x1c140000)
>>  
>>  /*
>>   * Begin of DECstation 5000/xx onboard framebuffer memory, default resolution
>>   * is 1024x768x8
>>   */
>> -#define DS5000_xx_ONBOARD_FBMEM_START	KSEG1ADDR(0x0a000000)
>> +#define DS5000_xx_ONBOARD_FBMEM_START	CKSEG1ADDR(0x0a000000)
>>  
>>  /*
>>   *      The IMS 332 video controller used in the DECstation 5000/xx series
> 
>  This would probably best be a separate change, especially as it's not 
> needed for 32BIT.
> 
>  I'm not sure how the actual maintainers see it (I should probably list 
> myself for all the scattered DECstation stuff), but I think this would 
> best be a patch series of 3 for each of the individual classes of fixes.  
> And since this borders on the obvious I wouldn't be too concerned as to 
> the change descriptions; just one sentence plus the relevant error message 
> quoted will do.  And your introduction should suffice as the cover letter.
> 
>  Let me know if this works for you and if you post such a series, I'll ack 
> it right away.

OK, I'll work on that.

-- 
~Randy


      reply	other threads:[~2026-08-13 21:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-09 23:48 [RFC PATCH] fbdev: maxinefb: fix build issues Randy Dunlap
     [not found] ` <20260810000251.55AD61F000E9@smtp.kernel.org>
2026-08-10  0:27   ` Randy Dunlap
2026-08-14  2:46     ` Randy Dunlap
2026-08-10  3:24 ` Philippe Mathieu-Daudé
2026-08-10  3:29   ` Randy Dunlap
2026-08-13 18:14     ` Maciej W. Rozycki
2026-08-13 16:11 ` Helge Deller
2026-08-13 18:16   ` Maciej W. Rozycki
2026-08-13 20:52     ` Helge Deller
2026-08-13 17:31 ` Maciej W. Rozycki
2026-08-13 21:46   ` Randy Dunlap [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4b67f1e-4afa-4d8b-bd28-28e8e991dfa4@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox