From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's
Date: Thu, 21 Oct 2010 10:05:42 +0200 [thread overview]
Message-ID: <201010211005.42866.arnd@arndb.de> (raw)
In-Reply-To: <1287608139-21354-1-git-send-email-alchark@gmail.com>
On Wednesday 20 October 2010 22:55:33 Alexey Charkov wrote:
> Please review and state whether this could be acceptable for a merge
> to mainline in the coming 2.6.37 window. If possible, I would deeply
> appreciate a merge to a relevant git tree for integration prior to
> asking Linus to pull the changes. I could rebase the code if needed,
> currently this is against Linus' master branch.
As Greg mentioned for his review of the serial drivers, it's too late
for 2.6.37. Fortunately that means you're really early for 2.6.38
and getting it in there should be easy.
The code does look very good though overall.
> +
> +choice
> + prompt "LCD panel size"
> + depends on (FB_VT8500 || FB_WM8505)
> + default WMT_PANEL_800X480
> +
> +config WMT_PANEL_800X480
> + bool "7-inch with 800x480 resolution"
> + help
> + These are found in most of the netbooks in generic cases, as
> + well as in Eken M001 tablets and possibly elsewhere.
> +
> +config WMT_PANEL_800X600
> + bool "8-inch with 800x600 resolution"
> + help
> + These are found in Eken M003 tablets and possibly elsewhere.
> +
> +config WMT_PANEL_1024X600
> + bool "10-inch with 1024x600 resolution"
> + help
> + These are found in Eken M006 tablets and possibly elsewhere.
> +
> +endchoice
This should really be a run-time or at least boot-time option. If you
set the frame buffer size at compile time, I guess you can no longer
boot on a machine that uses a different size.
> +#include <mach/vt8500.h>
> +#include "devices.h"
> +
> +static struct platform_device *devices[] __initdata = {
> + &vt8500_device_uart0,
> +#ifdef CONFIG_FB_VT8500
> + &vt8500_device_lcdc,
> +#endif
> +#ifdef CONFIG_USB_EHCI_HCD
> + &vt8500_device_ehci,
> +#endif
> +#ifdef CONFIG_FB_WMT_GE_ROPS
> + &vt8500_device_ge_rops,
> +#endif
> +#ifdef CONFIG_HAVE_PWM
> + &vt8500_device_pwm,
> +#endif
> +#ifdef CONFIG_BACKLIGHT_PWM
> + &vt8500_device_pwmbl,
> +#endif
> +#ifdef CONFIG_RTC_DRV_VT8500
> + &vt8500_device_rtc,
> +#endif
> +};
This doesn't work if the drivers are built as loadable modules, right?
I wouldn't even make the definitions of the devices configuration dependent.
The idea of the device model is that you describe what you have in one
place and use that information to load the drivers for it.
> +#ifdef CONFIG_VTWM_VERSION_WM8505
> +extern struct platform_device vt8500_device_uart4;
> +extern struct platform_device vt8500_device_uart5;
> +#endif
> +
> +#ifdef CONFIG_FB_VT8500
> +extern struct platform_device vt8500_device_lcdc;
> +#endif
> +#ifdef CONFIG_FB_WM8505
> +extern struct platform_device vt8500_device_wm8505_fb;
> +#endif
> +
> +#ifdef CONFIG_USB_EHCI_HCD
> +extern struct platform_device vt8500_device_ehci;
> +#endif
> +
> +#ifdef CONFIG_FB_WMT_GE_ROPS
> +extern struct platform_device vt8500_device_ge_rops;
> +#endif
> +#ifdef CONFIG_HAVE_PWM
> +extern struct platform_device vt8500_device_pwm;
> +#endif
> +#ifdef CONFIG_BACKLIGHT_PWM
> +extern struct platform_device vt8500_device_pwmbl;
> +#endif
> +#ifdef CONFIG_RTC_DRV_VT8500
> +extern struct platform_device vt8500_device_rtc;
> +#endif
The declarations never belong in an #ifdef, just make them
unconditional.
> +#ifndef __ASM_ARM_ARCH_IO_H
> +#define __ASM_ARM_ARCH_IO_H
> +
> +#define IO_SPACE_LIMIT 0xffffffff
> +
> +#define __io(a) __typesafe_io(a)
> +#define __mem_pci(a) (a)
> +
> +#endif
This won't work if you ever want to use the PCI on vt8505 with devices
that have I/O space mapping.
You need to define IO_SPACE_LIMIT to the size of your I/O space and
make the __io macro offset the address with the start of that window.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: vt8500-wm8505-linux-kernel@googlegroups.com
Cc: Alexey Charkov <alchark@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Russell King <linux@arm.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's
Date: Thu, 21 Oct 2010 10:05:42 +0200 [thread overview]
Message-ID: <201010211005.42866.arnd@arndb.de> (raw)
In-Reply-To: <1287608139-21354-1-git-send-email-alchark@gmail.com>
On Wednesday 20 October 2010 22:55:33 Alexey Charkov wrote:
> Please review and state whether this could be acceptable for a merge
> to mainline in the coming 2.6.37 window. If possible, I would deeply
> appreciate a merge to a relevant git tree for integration prior to
> asking Linus to pull the changes. I could rebase the code if needed,
> currently this is against Linus' master branch.
As Greg mentioned for his review of the serial drivers, it's too late
for 2.6.37. Fortunately that means you're really early for 2.6.38
and getting it in there should be easy.
The code does look very good though overall.
> +
> +choice
> + prompt "LCD panel size"
> + depends on (FB_VT8500 || FB_WM8505)
> + default WMT_PANEL_800X480
> +
> +config WMT_PANEL_800X480
> + bool "7-inch with 800x480 resolution"
> + help
> + These are found in most of the netbooks in generic cases, as
> + well as in Eken M001 tablets and possibly elsewhere.
> +
> +config WMT_PANEL_800X600
> + bool "8-inch with 800x600 resolution"
> + help
> + These are found in Eken M003 tablets and possibly elsewhere.
> +
> +config WMT_PANEL_1024X600
> + bool "10-inch with 1024x600 resolution"
> + help
> + These are found in Eken M006 tablets and possibly elsewhere.
> +
> +endchoice
This should really be a run-time or at least boot-time option. If you
set the frame buffer size at compile time, I guess you can no longer
boot on a machine that uses a different size.
> +#include <mach/vt8500.h>
> +#include "devices.h"
> +
> +static struct platform_device *devices[] __initdata = {
> + &vt8500_device_uart0,
> +#ifdef CONFIG_FB_VT8500
> + &vt8500_device_lcdc,
> +#endif
> +#ifdef CONFIG_USB_EHCI_HCD
> + &vt8500_device_ehci,
> +#endif
> +#ifdef CONFIG_FB_WMT_GE_ROPS
> + &vt8500_device_ge_rops,
> +#endif
> +#ifdef CONFIG_HAVE_PWM
> + &vt8500_device_pwm,
> +#endif
> +#ifdef CONFIG_BACKLIGHT_PWM
> + &vt8500_device_pwmbl,
> +#endif
> +#ifdef CONFIG_RTC_DRV_VT8500
> + &vt8500_device_rtc,
> +#endif
> +};
This doesn't work if the drivers are built as loadable modules, right?
I wouldn't even make the definitions of the devices configuration dependent.
The idea of the device model is that you describe what you have in one
place and use that information to load the drivers for it.
> +#ifdef CONFIG_VTWM_VERSION_WM8505
> +extern struct platform_device vt8500_device_uart4;
> +extern struct platform_device vt8500_device_uart5;
> +#endif
> +
> +#ifdef CONFIG_FB_VT8500
> +extern struct platform_device vt8500_device_lcdc;
> +#endif
> +#ifdef CONFIG_FB_WM8505
> +extern struct platform_device vt8500_device_wm8505_fb;
> +#endif
> +
> +#ifdef CONFIG_USB_EHCI_HCD
> +extern struct platform_device vt8500_device_ehci;
> +#endif
> +
> +#ifdef CONFIG_FB_WMT_GE_ROPS
> +extern struct platform_device vt8500_device_ge_rops;
> +#endif
> +#ifdef CONFIG_HAVE_PWM
> +extern struct platform_device vt8500_device_pwm;
> +#endif
> +#ifdef CONFIG_BACKLIGHT_PWM
> +extern struct platform_device vt8500_device_pwmbl;
> +#endif
> +#ifdef CONFIG_RTC_DRV_VT8500
> +extern struct platform_device vt8500_device_rtc;
> +#endif
The declarations never belong in an #ifdef, just make them
unconditional.
> +#ifndef __ASM_ARM_ARCH_IO_H
> +#define __ASM_ARM_ARCH_IO_H
> +
> +#define IO_SPACE_LIMIT 0xffffffff
> +
> +#define __io(a) __typesafe_io(a)
> +#define __mem_pci(a) (a)
> +
> +#endif
This won't work if you ever want to use the PCI on vt8505 with devices
that have I/O space mapping.
You need to define IO_SPACE_LIMIT to the size of your I/O space and
make the __io macro offset the address with the start of that window.
Arnd
next prev parent reply other threads:[~2010-10-21 8:05 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 20:55 [PATCH 1/6] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's Alexey Charkov
2010-10-20 20:55 ` Alexey Charkov
2010-10-20 20:55 ` [PATCH 2/6] serial: Add support for UART on VIA VT8500 and compatibles Alexey Charkov
2010-10-20 20:55 ` Alexey Charkov
2010-10-20 21:16 ` Greg KH
2010-10-20 21:16 ` Greg KH
2010-10-20 21:31 ` Alexey Charkov
2010-10-20 21:31 ` Alexey Charkov
2010-10-20 22:38 ` Greg KH
2010-10-20 22:38 ` Greg KH
2010-10-20 22:48 ` Alexey Charkov
2010-10-20 22:48 ` Alexey Charkov
2010-10-20 20:55 ` [PATCH 3/6] input: Add support for VIA VT8500 and compatibles in i8042 Alexey Charkov
2010-10-20 20:55 ` Alexey Charkov
2010-10-20 21:15 ` Dmitry Torokhov
2010-10-20 21:15 ` Dmitry Torokhov
2010-10-20 21:24 ` Alexey Charkov
2010-10-20 21:24 ` Alexey Charkov
2010-10-20 21:24 ` Alexey Charkov
2010-10-20 22:14 ` [PATCH 3/6 v2] " Alexey Charkov
2010-10-20 22:14 ` Alexey Charkov
2010-10-20 23:46 ` Dmitry Torokhov
2010-10-20 23:46 ` Dmitry Torokhov
2010-10-30 22:23 ` [PATCH 3/6] " Ben Dooks
2010-10-30 22:23 ` Ben Dooks
2010-11-01 18:31 ` Alexey Charkov
2010-11-01 18:31 ` Alexey Charkov
2010-11-01 18:31 ` Alexey Charkov
2010-10-20 20:55 ` [PATCH 4/6] usb: Add support for VIA VT8500 and compatibles in EHCI HCD Alexey Charkov
2010-10-20 20:55 ` Alexey Charkov
2010-10-20 21:17 ` Greg KH
2010-10-20 21:17 ` Greg KH
2010-10-20 22:41 ` Alexey Charkov
2010-10-20 22:41 ` Alexey Charkov
2010-10-20 22:47 ` Greg KH
2010-10-20 22:47 ` Greg KH
2010-10-20 22:54 ` Alexey Charkov
2010-10-20 22:54 ` Alexey Charkov
2010-10-20 20:55 ` [PATCH 5/6] rtc: Add support for the RTC in VIA VT8500 and compatibles Alexey Charkov
2010-10-20 20:55 ` Alexey Charkov
2010-10-20 20:55 ` [PATCH 6/6] ARM: Add support for the display controllers in VT8500 and WM8505 Alexey Charkov
2010-10-20 20:55 ` Alexey Charkov
2010-10-21 8:05 ` Arnd Bergmann [this message]
2010-10-21 8:05 ` [PATCH 1/6] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's Arnd Bergmann
2010-10-21 9:52 ` Alexey Charkov
2010-10-21 9:52 ` Alexey Charkov
2010-10-21 12:01 ` Arnd Bergmann
2010-10-21 12:01 ` Arnd Bergmann
2010-10-21 21:08 ` Alexey Charkov
2010-10-21 21:08 ` Alexey Charkov
2010-10-22 9:02 ` Arnd Bergmann
2010-10-22 9:02 ` Arnd Bergmann
2010-10-22 13:52 ` Alexey Charkov
2010-10-22 13:52 ` Alexey Charkov
2010-10-22 14:48 ` Arnd Bergmann
2010-10-22 14:48 ` Arnd Bergmann
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=201010211005.42866.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.