* [PATCH v2 00/77] SH pin control and GPIO rework with OF support
From: Laurent Pinchart @ 2012-11-27 0:01 UTC (permalink / raw)
To: linux-sh
Hi everybody,
Here's the second version of the SH pin control and GPIO rework patches. I've
added OF support for PFC instantiation and GPIO mappings that was missing from
v1. PINCTRL bindings are still missing and will come soon.
The first version of this patch set is available at
https://lkml.org/lkml/2012/11/20/823. I haven't applied the ack's I've received
on patches that have been extensively reworked in v2. Sorry for the
inconvenience. All comments received on v1 should have been addressed.
The GPIO DT bindings have been tested on an SH73A0 platform (KZM-A9-GT) with
the on-board GPIO LEDs. Please see patch 71/77 for a question regarding those
bindings.
The patches are still based on top of v3.7-rc6. You can get them from my git
tree at
git://linuxtv.org/pinchartl/fbdev.git pinmux
The code has been compile-tested on all modified platforms except SH7264 and
SH7269, and runtime tested on SH7372 (Mackerel), SH73A0 (KZM-A9-GT) and
R8A7740 (Armadillo) so far. I will runtime test it on R8A7779 (Marzen).
The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't
be compiled for them. As the currently implemented arch-level pinmux support
also depends on generic GPIO, we're moving from a situation where the code
isn't used to a different situation where the code isn't used. I don't
consider that as a regression.
Sorry for the numerous checkpatch warnings, patches that move code around or
rename files don't modify the content to make review easier, and thus carry
warnings from the existing code.
Changes since v1:
- Split SoC changes in one patch per SoC to make backporting easier
- Dropped SH7267 and SH7277 changes as support for those SoCs will be removed
from the kernel
- Removed the sh_pfc_register() function on ARM
- Added OF support for PFC instantiation and GPIO bindings
- Added PFC DT nodes for the Mackerel and KZM9G boards
- Added GPIO LEDs DT nodes for the KZM9G board
Laurent Pinchart (76):
sh-pfc: Split platform data from the sh_pfc structure
sh-pfc: Move private definitions and declarations to private header
sh-pfc: Merge PFC core and pinctrl
sh-pfc: Merge PFC core and gpio
sh-pfc: Move platform device and driver to the core
sh-pfc: Let the compiler decide whether to inline functions
sh-pfc: Remove check for impossible error condition
sh-pfc: Sort headers alphabetically
sh-pfc: Split platform device and platform driver registration
sh-pfc: Support passing resources through platform device
ARM: shmobile: Select PINCTRL
ARM: shmobile: r8a7740: Register PFC platform device
ARM: shmobile: r8a7779: Register PFC platform device
ARM: shmobile: sh7372: Register PFC platform device
ARM: shmobile: sh73a0: Register PFC platform device
ARM: shmobile: r8a7740: Add pin control resources
ARM: shmobile: sh7372: Add pin control resources
ARM: shmobile: sh73a0: Add pin control resources
sh: Add PFC platform device registration helper function
sh: sh7203: Register PFC platform device
sh: sh7264: Register PFC platform device
sh: sh7269: Register PFC platform device
sh: sh7720: Register PFC platform device
sh: sh7722: Register PFC platform device
sh: sh7723: Register PFC platform device
sh: sh7724: Register PFC platform device
sh: sh7734: Register PFC platform device
sh: sh7757: Register PFC platform device
sh: sh7785: Register PFC platform device
sh: sh7786: Register PFC platform device
sh: shx3: Register PFC platform device
sh-pfc: Remove platform device registration
sh-pfc: Remove unused resource and num_resources platform data fields
sh-pfc: Move driver from drivers/sh/ to drivers/pinctrl/
sh-pfc: Support pinmux info in driver data instead of platform data
sh-pfc: Add r8a7740 pinmux support
sh-pfc: Add r8a7779 pinmux support
sh-pfc: Add sh7372 pinmux support
sh-pfc: Add sh73a0 pinmux support
ARM: shmobile: r8a7740: Use driver-provided pinmux info
ARM: shmobile: r8a7779: Use driver-provided pinmux info
ARM: shmobile: sh7372: Use driver-provided pinmux info
ARM: shmobile: sh73a0: Use driver-provided pinmux info
sh-pfc: Add sh7203 pinmux support
sh-pfc: Add sh7264 pinmux support
sh-pfc: Add sh7269 pinmux support
sh-pfc: Add sh7720 pinmux support
sh-pfc: Add sh7722 pinmux support
sh-pfc: Add sh7723 pinmux support
sh-pfc: Add sh7724 pinmux support
sh-pfc: Add sh7734 pinmux support
sh-pfc: Add sh7757 pinmux support
sh-pfc: Add sh7785 pinmux support
sh-pfc: Add sh7786 pinmux support
sh-pfc: Add shx3 pinmux support
sh: sh7203: pinmux: Use driver-provided pinmux info
sh: sh7264: pinmux: Use driver-provided pinmux info
sh: sh7269: pinmux: Use driver-provided pinmux info
sh: sh7720: pinmux: Use driver-provided pinmux info
sh: sh7722: pinmux: Use driver-provided pinmux info
sh: sh7723: pinmux: Use driver-provided pinmux info
sh: sh7724: pinmux: Use driver-provided pinmux info
sh: sh7734: pinmux: Use driver-provided pinmux info
sh: sh7757: pinmux: Use driver-provided pinmux info
sh: sh7785: pinmux: Use driver-provided pinmux info
sh: sh7786: pinmux: Use driver-provided pinmux info
sh: shx3: pinmux: Use driver-provided pinmux info
sh: Remove unused sh_pfc_register_info() function
sh-pfc: Remove pinmux_info definition
sh-pfc: Move sh_pfc.h from include/linux/ to driver directory
sh-pfc: Add OF support
ARM: shmobile: r8a7740: Add pin control device in device tree
ARM: shmobile: armadillo: Populate platform devices from device tree
ARM: shmobile: kzm9g: Add pin control device in device tree
ARM: shmobile: kzm9g: Populate platform devices from device tree
ARM: shmobile: kzm9g: Add LED1-LED4 to the device tree
Nobuhiro Iwamatsu (1):
ARM: shmobile: Include DTSI of r8a7740 to armadillo800eva
.../bindings/pinctrl/renesas,pfc-pinctrl.txt | 43 +
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 +-
arch/arm/boot/dts/r8a7740.dtsi | 6 +
arch/arm/boot/dts/sh73a0-kzm9g.dts | 18 +-
arch/arm/boot/dts/sh73a0.dtsi | 32 +
arch/arm/mach-shmobile/Makefile | 5 -
arch/arm/mach-shmobile/board-armadillo800eva.c | 4 +-
arch/arm/mach-shmobile/board-kzm9g.c | 3 +-
arch/arm/mach-shmobile/setup-r8a7740.c | 26 +
arch/arm/mach-shmobile/setup-r8a7779.c | 25 +
arch/arm/mach-shmobile/setup-sh7372.c | 26 +
arch/arm/mach-shmobile/setup-sh73a0.c | 25 +
arch/sh/Kconfig | 12 +
arch/sh/include/asm/gpio.h | 2 +-
arch/sh/include/cpu-common/cpu/pfc.h | 26 +
arch/sh/kernel/cpu/Makefile | 2 +-
arch/sh/kernel/cpu/pfc.c | 33 +
arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c | 1582 +-----------
arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c | 2121 +---------------
arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 2823 +-------------------
arch/sh/kernel/cpu/sh3/pinmux-sh7720.c | 1226 +---------
arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c | 1778 +------------
arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c | 1893 +-------------
arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c | 2210 +---------------
arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c | 2470 +-----------------
arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c | 2267 +----------------
arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c | 1294 +---------
arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c | 822 +------
arch/sh/kernel/cpu/sh4a/pinmux-shx3.c | 573 +----
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/sh-pfc/Kconfig | 116 +
drivers/pinctrl/sh-pfc/Makefile | 21 +
drivers/{sh/pfc => pinctrl/sh-pfc}/core.c | 294 ++-
drivers/pinctrl/sh-pfc/core.h | 72 +
drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c | 111 +-
.../pinctrl/sh-pfc}/pfc-r8a7740.c | 11 +-
.../pinctrl/sh-pfc}/pfc-r8a7779.c | 29 +-
drivers/pinctrl/sh-pfc/pfc-sh7203.c | 1592 +++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7264.c | 2131 +++++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7269.c | 2834 ++++++++++++++++++++
.../pinctrl/sh-pfc}/pfc-sh7372.c | 11 +-
.../pinctrl/sh-pfc}/pfc-sh73a0.c | 11 +-
drivers/pinctrl/sh-pfc/pfc-sh7720.c | 1236 +++++++++
drivers/pinctrl/sh-pfc/pfc-sh7722.c | 1779 ++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7723.c | 1903 +++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7724.c | 2225 +++++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7734.c | 2475 +++++++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7757.c | 2282 ++++++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7785.c | 1304 +++++++++
drivers/pinctrl/sh-pfc/pfc-sh7786.c | 837 ++++++
drivers/pinctrl/sh-pfc/pfc-shx3.c | 582 ++++
drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c | 149 +-
{include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h | 43 +-
drivers/sh/Kconfig | 1 -
drivers/sh/Makefile | 1 -
drivers/sh/pfc/Kconfig | 26 -
drivers/sh/pfc/Makefile | 3 -
59 files changed, 22007 insertions(+), 21424 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
create mode 100644 arch/sh/include/cpu-common/cpu/pfc.h
create mode 100644 arch/sh/kernel/cpu/pfc.c
create mode 100644 drivers/pinctrl/sh-pfc/Kconfig
create mode 100644 drivers/pinctrl/sh-pfc/Makefile
rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.c (62%)
create mode 100644 drivers/pinctrl/sh-pfc/core.h
rename drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c (59%)
rename {arch/arm/mach-shmobile => drivers/pinctrl/sh-pfc}/pfc-r8a7740.c (99%)
rename {arch/arm/mach-shmobile => drivers/pinctrl/sh-pfc}/pfc-r8a7779.c (99%)
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7203.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7264.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7269.c
rename {arch/arm/mach-shmobile => drivers/pinctrl/sh-pfc}/pfc-sh7372.c (99%)
rename {arch/arm/mach-shmobile => drivers/pinctrl/sh-pfc}/pfc-sh73a0.c (99%)
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7720.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7722.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7723.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7724.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7734.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7757.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7785.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7786.c
create mode 100644 drivers/pinctrl/sh-pfc/pfc-shx3.c
rename drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c (76%)
rename {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h (83%)
delete mode 100644 drivers/sh/pfc/Kconfig
delete mode 100644 drivers/sh/pfc/Makefile
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Build regressions/improvements in v3.7-rc7
From: Geert Uytterhoeven @ 2012-11-26 20:56 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Linux-sh list
In-Reply-To: <1353963243-21887-1-git-send-email-geert@linux-m68k.org>
On Mon, Nov 26, 2012 at 9:54 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.7-rc7 to v3.7-rc6[3], the summaries are:
> - build errors: +4/-8
+ error: "__sync_fetch_and_and_4"
[drivers/staging/line6/line6usb.ko] undefined!: => N/A
+ error: "__sync_fetch_and_or_4" [drivers/staging/line6/line6usb.ko]
undefined!: => N/A
sh4/sh-randconfig
+ error: "smp_send_reschedule" [arch/powerpc/kvm/kvm.ko] undefined!: => N/A
powerpc/powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/5646/ (all 117 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/5628/ (all 117 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/9] dma_debug: add debug_dma_mapping_error support to architectures that support DMA_DEB
From: Shuah Khan @ 2012-11-26 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121126112217.GG25742@8bytes.org>
On Mon, 2012-11-26 at 12:22 +0100, Joerg Roedel wrote:
> Hi Shuah,
>
> On Fri, Nov 23, 2012 at 02:29:02PM -0700, Shuah Khan wrote:
> > x86 - done in the first patch that added the feature.
> >
> > ARM64: dma_debug: add debug_dma_mapping_error support
> > c6x: dma_debug: add debug_dma_mapping_error support
> > ia64: dma_debug: add debug_dma_mapping_error support
> > microblaze: dma-mapping: support debug_dma_mapping_error
> > mips: dma_debug: add debug_dma_mapping_error support
> > powerpc: dma_debug: add debug_dma_mapping_error support
> > sh: dma_debug: add debug_dma_mapping_error support
> > sparc: dma_debug: add debug_dma_mapping_error support
> > tile: dma_debug: add debug_dma_mapping_error support
>
> Have you compile-tested the invididual archs you are changing here?
>
Joerg,
Yes I compile tested all of them (except microblaze) on Nov 20th
linux_next git. The patch for microblaze is already in linux_next when I
tried to apply the patch to Nov 20th linux-next and figured that is
already covered and skipped that one.
-- Shuah
^ permalink raw reply
* Re: [PATCH v3 11/12] memory-hotplug: remove sysfs file of node
From: Jianguo Wu @ 2012-11-26 14:27 UTC (permalink / raw)
To: Wen Congyang
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi, linux-s390,
linux-sh, linux-ia64, cmetcalf, sparclinux, David Rientjes,
Jiang Liu, Len Brown, benh, paulus, Christoph Lameter,
Minchan Kim, Andrew Morton, KOSAKI Motohiro, Yasuaki Ishimatsu,
Jianguo Wu
In-Reply-To: <1351763083-7905-12-git-send-email-wency@cn.fujitsu.com>
On 2012/11/1 17:44, Wen Congyang wrote:
> This patch introduces a new function try_offline_node() to
> remove sysfs file of node when all memory sections of this
> node are removed. If some memory sections of this node are
> not removed, this function does nothing.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 8 +++++-
> include/linux/memory_hotplug.h | 2 +-
> mm/memory_hotplug.c | 58 ++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 64 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 24c807f..0780f99 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -310,7 +310,9 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
> {
> int result;
> struct acpi_memory_info *info, *n;
> + int node;
>
> + node = acpi_get_node(mem_device->device->handle);
>
> /*
> * Ask the VM to offline this memory range.
> @@ -318,7 +320,11 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
> */
> list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
> if (info->enabled) {
> - result = remove_memory(info->start_addr, info->length);
> + if (node < 0)
> + node = memory_add_physaddr_to_nid(
> + info->start_addr);
> + result = remove_memory(node, info->start_addr,
> + info->length);
> if (result)
> return result;
> }
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index d4c4402..7b4cfe6 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -231,7 +231,7 @@ extern int arch_add_memory(int nid, u64 start, u64 size);
> extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
> extern int offline_memory_block(struct memory_block *mem);
> extern bool is_memblock_offlined(struct memory_block *mem);
> -extern int remove_memory(u64 start, u64 size);
> +extern int remove_memory(int node, u64 start, u64 size);
> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
> int nr_pages);
> extern void sparse_remove_one_section(struct zone *zone, struct mem_section *ms);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 7bcced0..d965da3 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -29,6 +29,7 @@
> #include <linux/suspend.h>
> #include <linux/mm_inline.h>
> #include <linux/firmware-map.h>
> +#include <linux/stop_machine.h>
>
> #include <asm/tlbflush.h>
>
> @@ -1299,7 +1300,58 @@ static int is_memblock_offlined_cb(struct memory_block *mem, void *arg)
> return ret;
> }
>
> -int __ref remove_memory(u64 start, u64 size)
> +static int check_cpu_on_node(void *data)
> +{
> + struct pglist_data *pgdat = data;
> + int cpu;
> +
> + for_each_present_cpu(cpu) {
> + if (cpu_to_node(cpu) = pgdat->node_id)
> + /*
> + * the cpu on this node isn't removed, and we can't
> + * offline this node.
> + */
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
> +/* offline the node if all memory sections of this node are removed */
> +static void try_offline_node(int nid)
> +{
> + unsigned long start_pfn = NODE_DATA(nid)->node_start_pfn;
> + unsigned long end_pfn = start_pfn + NODE_DATA(nid)->node_spanned_pages;
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(pfn);
> +
> + if (!present_section_nr(section_nr))
> + continue;
> +
> + if (pfn_to_nid(pfn) != nid)
> + continue;
> +
> + /*
> + * some memory sections of this node are not removed, and we
> + * can't offline node now.
> + */
> + return;
> + }
> +
> + if (stop_machine(check_cpu_on_node, NODE_DATA(nid), NULL))
> + return;
how about:
if (nr_cpus_node(nid))
return;
> +
> + /*
> + * all memory/cpu of this node are removed, we can offline this
> + * node now.
> + */
> + node_set_offline(nid);
> + unregister_one_node(nid);
> +}
> +
> +int __ref remove_memory(int nid, u64 start, u64 size)
> {
> unsigned long start_pfn, end_pfn;
> int ret = 0;
> @@ -1346,6 +1398,8 @@ repeat:
>
> arch_remove_memory(start, size);
>
> + try_offline_node(nid);
> +
> unlock_memory_hotplug();
>
> return 0;
> @@ -1355,7 +1409,7 @@ int offline_pages(unsigned long start_pfn, unsigned long nr_pages)
> {
> return -EINVAL;
> }
> -int remove_memory(u64 start, u64 size)
> +int remove_memory(int nid, u64 start, u64 size)
> {
> return -EINVAL;
> }
>
^ permalink raw reply
* Re: [PATCH 4/7] ARM: shmobile: pfc-sh73a0: Register device tree
From: Laurent Pinchart @ 2012-11-26 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353889014-17142-5-git-send-email-horms@verge.net.au>
Hi Simon,
On Monday 26 November 2012 09:16:51 Simon Horman wrote:
> Register the pfc with sh73a0_init_gpio_dt() to allow
> gpios provided by pfc to be accessed by devices which
> are registered using device tree.
>
> The motivation of this is to allow the gpio used for carrier detect
> but the Micro SD SDHI port of the KZM-9A-GT board to be accessed
> using device tree. Thus, allowing the SDHI device of the KZM-9A-GT
> board to be registered using device tree.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> arch/arm/mach-shmobile/pfc-sh73a0.c | 45 ++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm/mach-shmobile/pfc-sh73a0.c
> b/arch/arm/mach-shmobile/pfc-sh73a0.c index b442f9d..d1a04c0b 100644
> --- a/arch/arm/mach-shmobile/pfc-sh73a0.c
> +++ b/arch/arm/mach-shmobile/pfc-sh73a0.c
> @@ -2797,7 +2797,52 @@ static struct pinmux_info sh73a0_pinmux_info = {
> .gpio_irq_size = ARRAY_SIZE(pinmux_irqs),
> };
>
> +#ifdef CONFIG_OF_GPIO
> +static int sh73a0_gpio_xlate(struct gpio_chip *gc,
> + const struct of_phandle_args *gpiospec,
> + u32 *flags)
> +{
> + if (WARN_ON(gc->of_gpio_n_cells < 2))
> + return -EINVAL;
> +
> + if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
> + return -EINVAL;
> +
> + if (gpiospec->args[0] > gc->ngpio)
> + return -EINVAL;
> +
> + if (flags)
> + *flags = gpiospec->args[1];
> +
> + return gpiospec->args[0];
> +}
Is there any reason not to use of_gpio_simple_xlate here ? If there isn't,
of_xlate and of_gpio_n_cells default to of_gpio_simple_xlate and 2
respectively when of_xlate isn't specified, so you could omit both.
> +static const struct of_device_id sh73a0_gpio_dt_match[] __initdata = {
> + { .compatible = "renesas,sh_pfc-sh73a0", },
> + {}
> +};
> +
> +static inline void sh73a0_init_gpio_dt(void)
> +{
> + struct device_node *of_node;
> +
> + if (!of_have_populated_dt())
> + return;
> +
> + of_node = of_find_matching_node(NULL, sh73a0_gpio_dt_match);
> + sh73a0_pinmux_info.of_node = of_node;
> + sh73a0_pinmux_info.of_gpio_n_cells = 2;
> + sh73a0_pinmux_info.of_xlate = sh73a0_gpio_xlate;
> +}
> +
> +#else
> +
> +static inline void sh73a0_init_gpio_dt(void) {}
> +
> +#endif
> +
> void sh73a0_pinmux_init(void)
> {
> + sh73a0_init_gpio_dt();
> register_pinmux(&sh73a0_pinmux_info);
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 3/7] sh: pfc: Allow device tree registration
From: Laurent Pinchart @ 2012-11-26 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353889014-17142-4-git-send-email-horms@verge.net.au>
Hi Simon,
On Monday 26 November 2012 09:16:50 Simon Horman wrote:
> This is a crude mechanism to allow the pfc driver to be registered through
> device tree. The mofication of this is to provide a way for pfc gpios to be
> looked up by device tree for devices which use pfc gpios.
Indeed it's a bit of a hack :-) I'll see how I can rebase that on top of my
PFC patch series. I'd rather avoid this intermediate step as it would make PFC
rework more complex.
> More specifically, the motivation is to allow the registration
> of the card-detect gpio for the Micro-SD SDHI slot of the KZM9G board.
>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> drivers/sh/pfc/gpio.c | 15 +++++++++++++++
> include/linux/sh_pfc.h | 7 +++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/sh/pfc/gpio.c b/drivers/sh/pfc/gpio.c
> index 038fa07..322b927 100644
> --- a/drivers/sh/pfc/gpio.c
> +++ b/drivers/sh/pfc/gpio.c
> @@ -136,6 +136,19 @@ static void sh_pfc_gpio_setup(struct sh_pfc_chip *chip)
> gc->ngpio = (pfc->last_gpio - pfc->first_gpio) + 1;
> }
>
> +#ifdef CONFIG_OF_GPIO
> +static void
> +sh_pfc_register_gpiochip_dt(struct sh_pfc *pfc, struct gpio_chip *chip)
> +{
> + chip->of_node = pfc->of_node;
> + chip->of_gpio_n_cells = pfc->of_gpio_n_cells;
> + chip->of_xlate = pfc->of_xlate;
> +}
> +#else
> +static void sh_pfc_register_gpiochip_dt(struct sh_pfc *pfc,
> + struct gpio_chip *chip) {}
> +#endif
> +
> int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
> {
> struct sh_pfc_chip *chip;
> @@ -153,6 +166,8 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
> if (unlikely(ret < 0))
> kfree(chip);
>
> + sh_pfc_register_gpiochip_dt(pfc, &chip->gpio_chip);
> +
> pr_info("%s handling gpio %d -> %d\n",
> pfc->name, pfc->first_gpio, pfc->last_gpio);
>
> diff --git a/include/linux/sh_pfc.h b/include/linux/sh_pfc.h
> index c19a092..9963370 100644
> --- a/include/linux/sh_pfc.h
> +++ b/include/linux/sh_pfc.h
> @@ -124,6 +124,13 @@ struct sh_pfc {
> struct pfc_window *window;
>
> unsigned long unlock_reg;
> +
> +#ifdef CONFIG_OF_GPIO
> + struct device_node *of_node;
> + int of_gpio_n_cells;
> + int (*of_xlate)(struct gpio_chip *gc,
> + const struct of_phandle_args *gpiospec, u32 *flags);
> +#endif
> };
>
> /* XXX compat for now */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 6/7] ARM: mach-shmobile: sh73a0: Minimal setup using DT
From: Laurent Pinchart @ 2012-11-26 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121126045805.GC12790@verge.net.au>
Hi Simon,
On Monday 26 November 2012 13:58:06 Simon Horman wrote:
> On Mon, Nov 26, 2012 at 01:23:12PM +0900, Magnus Damm wrote:
> > On Mon, Nov 26, 2012 at 9:16 AM, Simon Horman <horms@verge.net.au> wrote:
> > > Allow a minimal setup of the sh73a0 SoC using a flattened device tree.
> > >
> > > * Allow configuration of the i2c controllers using a flattened device
> > > tree.
> > >
> > > * SCI serial controller and CMT clock source, whose drivers do not yet
> > > support configuration using a flattened device tree, are still
> > > configured
> > > using C code in order to allow booting of a board with this SoC.
> > >
> > > An example dts snuppet follows:
> > > i2c0: i2c@0xe6820000 {
> > >
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > compatible = "renesas,rmobile-iic";
> > > reg = <0xe6820000 0x425>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <0 167 0x4
> > >
> > > 0 170 0x4>;
> > >
> > > };
> > >
> > > i2c1: i2c@0xe6822000 {
> > >
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > compatible = "renesas,rmobile-iic";
> > > reg = <0xe6822000 0x425>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <0 51 0x4
> > >
> > > 0 44 0x4>;
> > >
> > > touchscreen@55 {
> > >
> > > compatible = "sitronix,st1232";
> > > reg = <0x55>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <0 9 0x4>;
> > >
> > > };
> > >
> > > };
> > >
> > > i2c2: i2c@0xe6824000 {
> > >
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > compatible = "renesas,rmobile-iic";
> > > reg = <0xe6824000 0x425>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <0 171 0x4
> > >
> > > 0 174 0x4>;
> > >
> > > };
> > >
> > > i2c3: i2c@0xe6826000 {
> > >
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > compatible = "renesas,rmobile-iic";
> > > reg = <0xe6826000 0x425>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <0 183 0x4
> > >
> > > 0 186 0x4>;
> > >
> > > };
> > >
> > > i2c4: i2c@0xe6828000 {
> > >
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > compatible = "renesas,rmobile-iic";
> > > reg = <0xe6828000 0x425>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <0 187 0x4
> > >
> > > 0 190 0x4>;
> > >
> > > };
> >
> > Uhm, doesn't the above want to go into sh73a0.dtsi?
>
> There are two things that I am unsure of:
>
> * What should go into sh73a0.dtsi and what should go into
> sh73a0-kzm9g-refere3nce.dts.
>
> The i2c seems like it should go into sh73a0.dtsi as it is part of the
> soc. Likewise the interrupt controllers.
>
> But when it comes to mmcif and sdhi I am less sure. Both of these make use
> of regulators. Are the regulators part of the board or the SoC?
It depends on the regulators. In theory you could have on-SoC regulators that
would thus be part of the SoC. In practice I'm not sure how often that
happens.
Most of the regulators are provided by the PMIC, so we can create PMIC-
specific .dtsi files that would be included by boards. See twl4030.dtsi for an
example. Other board-specific regulators, including fixed regulators, should
be provided by the board.
> If the are part of the board then it makes it more difficult to put mmcif
> and sdhi into sh73a0.dtsi as they need to reference the regulators
> somehow.
I think you can split a node across several files. You could have
mmcif: mmcif@0x10010000 {
compatible = "renesas,sh-mmcif";
reg = <0xe6bd0000 0x100>;
interrupt-parent = <&gic>;
interrupts = <0 140 0x4
0 141 0x4>;
reg-io-width = <4>;
};
in the SoC .dtsi, and
&mmcif {
vmmc-supply = <&fixedregulator1v8>;
vqmmc-supply = <&fixedregulator1v8>;
};
in the board .dts.
> * What to do the of_dev_auxdata.
>
> Currently I add this in patch 4 to the board-kzm9g.c. It is used to force
> the name of the i2c, mmcif and sdhi devices in order to allow their clock
> lookup to work (though come to think of it it may not be necessary for
> mmcif and sdhi).
Shouldn't clocks be specified as an attribute in DT nodes that reference the
clock node ?
> In any case, the location of the of_dev_auxdata might be come a bit
> tricky if it covers devices in both the board and SoC dts files.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Laurent Pinchart @ 2012-11-26 11:59 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Laurent Pinchart, jg1.han, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto
In-Reply-To: <50B347F4.2080705@metafoo.de>
Hi Lars-Peter,
On Monday 26 November 2012 11:44:04 Lars-Peter Clausen wrote:
> On 11/26/2012 10:49 AM, Jingoo Han wrote:
> > On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
>
> [...]
>
> >> +static int gpio_backlight_check_fb(struct backlight_device *bl,
> >> + struct fb_info *info)
> >> +{
> >> + struct gpio_backlight *gbl = bl_get_data(bl);
> >> +
> >> + return gbl->fbdev = info->dev;
>
> I think it makes sense to return true if fbdev is NULL, to provide a simple
> fallback for systems with only one framebuffer device.
Agreed, I'll change that.
> >> +}
> >> +
>
> [...]
>
> >> +#ifdef CONFIG_PM
> >> +static int gpio_backlight_suspend(struct device *dev)
> >> +{
> >> + struct backlight_device *bl = dev_get_drvdata(dev);
> >> + struct gpio_backlight *gbl = bl_get_data(bl);
> >> +
> >> + gpio_set_value(gbl->gpio, !gbl->active);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int gpio_backlight_resume(struct device *dev)
> >> +{
> >> + struct backlight_device *bl = dev_get_drvdata(dev);
> >> +
> >> + backlight_update_status(bl);
> >> + return 0;
> >> +}
>
> If you use BL_CORE_SUSPENDRESUME you can get rid of the custom
> suspend/resume handlers.
Good point, I'll do that.
> >> +
> >> +static SIMPLE_DEV_PM_OPS(gpio_backlight_pm_ops, gpio_backlight_suspend,
> >> + gpio_backlight_resume);
> >> +
> >> +#endif
> >> +
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 0/9] dma_debug: add debug_dma_mapping_error support to architectures that support DMA_DEB
From: Joerg Roedel @ 2012-11-26 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353706142.5270.93.camel@lorien2>
Hi Shuah,
On Fri, Nov 23, 2012 at 02:29:02PM -0700, Shuah Khan wrote:
> x86 - done in the first patch that added the feature.
>
> ARM64: dma_debug: add debug_dma_mapping_error support
> c6x: dma_debug: add debug_dma_mapping_error support
> ia64: dma_debug: add debug_dma_mapping_error support
> microblaze: dma-mapping: support debug_dma_mapping_error
> mips: dma_debug: add debug_dma_mapping_error support
> powerpc: dma_debug: add debug_dma_mapping_error support
> sh: dma_debug: add debug_dma_mapping_error support
> sparc: dma_debug: add debug_dma_mapping_error support
> tile: dma_debug: add debug_dma_mapping_error support
Have you compile-tested the invididual archs you are changing here?
Joerg
^ permalink raw reply
* Re: [PATCH 0/9] dma_debug: add debug_dma_mapping_error support to architectures that support DMA_DEB
From: Joerg Roedel @ 2012-11-26 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50B34B0F.3080204@samsung.com>
On Mon, Nov 26, 2012 at 11:57:19AM +0100, Marek Szyprowski wrote:
> I've took all the patches to the next-dma-debug branch in my tree, I sorry
> that You have to wait so long for it. My branch is based on Joerg's
> dma-debug branch and I've included it for testing in linux-next branch.
>
> Joerg: would You mind if I handle pushing the whole branch to v3.8
> via my kernel tree? Those changes should be kept close together to
> avoid build breaks for bisecting.
I'll apply the patches to my tree soon enough. But before that I'll wait
a little bit longer to give the arch maintainers the chance to add the
missing Acked-bys.
Joerg
^ permalink raw reply
* Re: [PATCH 0/9] dma_debug: add debug_dma_mapping_error support to architectures that support DMA_DEB
From: Marek Szyprowski @ 2012-11-26 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353706142.5270.93.camel@lorien2>
Hello,
On 11/23/2012 10:29 PM, Shuah Khan wrote:
> An earlier patch added dma mapping error debug feature to dma_debug
> infrastructure. References:
>
> https://lkml.org/lkml/2012/10/8/296
> https://lkml.org/lkml/2012/11/3/219
>
> The following series of patches adds the call to debug_dma_mapping_error() to
> architecture specific dma_mapping_error() interfaces on the following
> architectures that support CONFIG_DMA_API_DEBUG.
I've took all the patches to the next-dma-debug branch in my tree, I sorry
that You have to wait so long for it. My branch is based on Joerg's
dma-debug branch and I've included it for testing in linux-next branch.
Joerg: would You mind if I handle pushing the whole branch to v3.8
via my kernel tree? Those changes should be kept close together to
avoid build breaks for bisecting.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Lars-Peter Clausen @ 2012-11-26 10:44 UTC (permalink / raw)
To: Laurent Pinchart
Cc: jg1.han, akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-sh@vger.kernel.org, linux-fbdev@vger.kernel.org, Paul Mundt,
Magnus Damm, Richard Purdie, Kuninori Morimoto
In-Reply-To: <32552643.33371353923376540.JavaMail.weblogic@epv6ml07>
On 11/26/2012 10:49 AM, Jingoo Han wrote:
> On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
[...]
>> +static int gpio_backlight_check_fb(struct backlight_device *bl,
>> + struct fb_info *info)
>> +{
>> + struct gpio_backlight *gbl = bl_get_data(bl);
>> +
>> + return gbl->fbdev = info->dev;
I think it makes sense to return true if fbdev is NULL, to provide a simple
fallback for systems with only one framebuffer device.
>> +}
>> +
[...]
>> +#ifdef CONFIG_PM
>> +static int gpio_backlight_suspend(struct device *dev)
>> +{
>> + struct backlight_device *bl = dev_get_drvdata(dev);
>> + struct gpio_backlight *gbl = bl_get_data(bl);
>> +
>> + gpio_set_value(gbl->gpio, !gbl->active);
>> +
>> + return 0;
>> +}
>> +
>> +static int gpio_backlight_resume(struct device *dev)
>> +{
>> + struct backlight_device *bl = dev_get_drvdata(dev);
>> +
>> + backlight_update_status(bl);
>> + return 0;
>> +}
If you use BL_CORE_SUSPENDRESUME you can get rid of the custom
suspend/resume handlers.
>> +
>> +static SIMPLE_DEV_PM_OPS(gpio_backlight_pm_ops, gpio_backlight_suspend,
>> + gpio_backlight_resume);
>> +
>> +#endif
>> +
[...]
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Laurent Pinchart @ 2012-11-26 10:25 UTC (permalink / raw)
To: jg1.han
Cc: Laurent Pinchart, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto
In-Reply-To: <32552643.33371353923376540.JavaMail.weblogic@epv6ml07>
Hi Jingoo,
On Monday 26 November 2012 09:49:36 Jingoo Han wrote:
> On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> CC'ed Andrew Morton
>
> It looks good. Also, I tested this patch with SMDK4210 board.
> Acked-by: Jingoo Han <jg1.han@samsung.com>
Thank you.
Unless Richard wants to take 1/5 and 2/5, I plan to push them through either
the Renesas ARM or Renesas SH tree with the board code patches.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/7] mmc: sdhi: enchance OF support for flags and cd-gpios
From: Guennadi Liakhovetski @ 2012-11-26 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353889014-17142-3-git-send-email-horms@verge.net.au>
On Mon, 26 Nov 2012, Simon Horman wrote:
Sorry, forgot to mention: it is always good to add
devicetree-discuss@lists.ozlabs.org to such patches, also we need a
document undet Documentation/devicetree/bindings/mmc/.
Thanks
Guennadi
> Enhance the OF support for SDHI by adding the following bindings:
>
> * renesas,shmobile-sdhi-has-idle-wait:
> Equivalent to setting TMIO_MMC_HAS_IDLE_WAIT in
> the flags of platform data
>
> * renesas,shmobile-sdhi-use-gpio-cd:
> Equivalent to setting TMIO_MMC_USE_GPIO_CD in
> the flags of platform data
>
> * renesas,shmobile-sdhi-wrprotect-disable:
> Equivalent to setting TMIO_MMC_WRPROTECT_DISABLE in
> the flags of platform data
>
> * cd-gpios:
> Equivalent to setting cd_gpio in platform data
>
> This patch also requests the clock based on the device tree
> node name if the platform data is absent.
>
> The motivation for this is to allow registration of the SDHI
> device of the KZM-A9-GT board through device tree.
>
> The following device tree snippet illustrates the use of the bindings
> described above.
>
> sdhi0@0xee100000 {
> compatible = "renesas,shmobile-sdhi";
> reg = <0xee100000 0x100>;
> interrupt-parent = <&gic>;
> interrupts = <0 83 0x4
> 0 84 0x4
> 0 85 0x4>;
> interrupt-names = "card_detect", "sdcard", "sdio";
> reg-io-width = <2>;
> vmmc-supply = <&fixedregulator2v8>;
> vqmmc-supply = <&fixedregulator2v8>;
> renesas,shmobile-sdhi-has-idle-wait;
> };
>
> sdhi2@0xee140000 {
> compatible = "renesas,shmobile-sdhi";
> reg = <0xee140000 0x100>;
> interrupt-parent = <&gic>;
> interrupts = <0 103 0x4
> 0 104 0x4
> 0 105 0x4>;
> interrupt-names = "card_detect", "sdcard", "sdio";
> reg-io-width = <2>;
> vmmc-supply = <&fixedregulator2v8>;
> vqmmc-supply = <&fixedregulator2v8>;
> renesas,shmobile-sdhi-has-idle-wait;
> renesas,shmobile-sdhi-use-gpio-cd;
> renesas,shmobile-sdhi-wrprotect-disable;
> cd-gpios = <&gpio 13 1>;
> };
>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> drivers/mmc/host/sh_mobile_sdhi.c | 76 +++++++++++++++++++++++++++++++------
> 1 file changed, 65 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
> index 0bdc146..8c7e658 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -29,6 +29,7 @@
> #include <linux/mfd/tmio.h>
> #include <linux/sh_dma.h>
> #include <linux/delay.h>
> +#include <linux/of_gpio.h>
>
> #include "tmio_mmc.h"
>
> @@ -117,13 +118,64 @@ static const struct sh_mobile_sdhi_ops sdhi_ops = {
> .cd_wakeup = sh_mobile_sdhi_cd_wakeup,
> };
>
> +static int __devinit
> +sh_mobile_sdhi_probe_clk(struct platform_device *pdev,
> + struct sh_mobile_sdhi *priv,
> + const char *clk_name)
> +{
> + priv->clk = clk_get(&pdev->dev, clk_name);
> + if (IS_ERR(priv->clk)) {
> + dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> + return PTR_ERR(priv->clk);
> + }
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static int __devinit
> +sh_mobile_sdhi_probe_config_dt(struct platform_device *pdev,
> + struct sh_mobile_sdhi *priv)
> +{
> + struct tmio_mmc_data *mmc_data = &priv->mmc_data;
> + struct device_node *np = pdev->dev.of_node;
> + int ret;
> +
> + BUG_ON(!np);
> +
> + ret = sh_mobile_sdhi_probe_clk(pdev, priv, np->name);
> + if (ret)
> + return ret;
> +
> + ret = of_get_named_gpio(np, "cd-gpios", 0);
> + if (gpio_is_valid(ret))
> + mmc_data->cd_gpio = ret;
> +
> + if (of_get_property(np, "renesas,shmobile-sdhi-has-idle-wait", NULL))
> + mmc_data->flags |= TMIO_MMC_HAS_IDLE_WAIT;
> + if (of_get_property(np, "renesas,shmobile-sdhi-use-gpio-cd", NULL))
> + mmc_data->flags |= TMIO_MMC_USE_GPIO_CD;
> + if (of_get_property(np, "renesas,shmobile-sdhi-wrprotect-disable",
> + NULL))
> + mmc_data->flags |= TMIO_MMC_WRPROTECT_DISABLE;
> +
> + return 0;
> +}
> +#else
> +static int __devinit
> +sh_mobile_sdhi_probe_config_dt(struct platform_device *pdev,
> + struct sh_mobile_sdhi *priv)
> +{
> + return 0;
> +}
> +#endif
> +
> static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
> {
> struct sh_mobile_sdhi *priv;
> struct tmio_mmc_data *mmc_data;
> struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
> struct tmio_mmc_host *host;
> - char clk_name[8];
> int irq, ret, i = 0;
> bool multiplexed_isr = true;
>
> @@ -144,21 +196,17 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
> }
> }
>
> - snprintf(clk_name, sizeof(clk_name), "sdhi%d", pdev->id);
> - priv->clk = clk_get(&pdev->dev, clk_name);
> - if (IS_ERR(priv->clk)) {
> - dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> - ret = PTR_ERR(priv->clk);
> - goto eclkget;
> - }
> -
> mmc_data->clk_enable = sh_mobile_sdhi_clk_enable;
> mmc_data->clk_disable = sh_mobile_sdhi_clk_disable;
> mmc_data->capabilities = MMC_CAP_MMC_HIGHSPEED;
> if (p) {
> + char clk_name[8];
> + snprintf(clk_name, sizeof(clk_name), "sdhi%d", pdev->id);
> + ret = sh_mobile_sdhi_probe_clk(pdev, priv, clk_name);
> + if (ret)
> + goto eclkget;
> +
> mmc_data->flags = p->tmio_flags;
> - if (mmc_data->flags & TMIO_MMC_HAS_IDLE_WAIT)
> - mmc_data->write16_hook = sh_mobile_sdhi_write16_hook;
> mmc_data->ocr_mask = p->tmio_ocr_mask;
> mmc_data->capabilities |= p->tmio_caps;
> mmc_data->capabilities2 |= p->tmio_caps2;
> @@ -176,7 +224,13 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
> priv->dma_priv.alignment_shift = 1; /* 2-byte alignment */
> mmc_data->dma = &priv->dma_priv;
> }
> + } else {
> + ret = sh_mobile_sdhi_probe_config_dt(pdev, priv);
> + if (ret)
> + goto eclkget;
> }
> + if (mmc_data->flags & TMIO_MMC_HAS_IDLE_WAIT)
> + mmc_data->write16_hook = sh_mobile_sdhi_write16_hook;
>
> /*
> * All SDHI blocks support 2-byte and larger block sizes in 4-bit
> --
> 1.7.10.4
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 2/7] mmc: sdhi: enchance OF support for flags and cd-gpios
From: Guennadi Liakhovetski @ 2012-11-26 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353889014-17142-3-git-send-email-horms@verge.net.au>
Hi Simon
Thanks for the patch, please, see some comments inline.
On Mon, 26 Nov 2012, Simon Horman wrote:
> Enhance the OF support for SDHI by adding the following bindings:
>
> * renesas,shmobile-sdhi-has-idle-wait:
> Equivalent to setting TMIO_MMC_HAS_IDLE_WAIT in
> the flags of platform data
>
> * renesas,shmobile-sdhi-use-gpio-cd:
> Equivalent to setting TMIO_MMC_USE_GPIO_CD in
> the flags of platform data
>
> * renesas,shmobile-sdhi-wrprotect-disable:
> Equivalent to setting TMIO_MMC_WRPROTECT_DISABLE in
> the flags of platform data
>
> * cd-gpios:
> Equivalent to setting cd_gpio in platform data
>
> This patch also requests the clock based on the device tree
> node name if the platform data is absent.
I'm not sure this is a good idea. IIUC, the idea is, that you either only
have one clock, then you don't use a name, or you use several clocks, then
your driver should know the names and what each of them is used for. See,
e.g. drivers/mtd/nand/gpmi-nand/gpmi-nand.c::gpmi_get_clks()
static char *extra_clks_for_mx6q[GPMI_CLK_MAX] = {
"gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch",
};
static int __devinit gpmi_get_clks(struct gpmi_nand_data *this)
{
...
/* The main clock is stored in the first. */
r->clock[0] = clk_get(this->dev, "gpmi_io");
etc., and clock declaration in arch/arm/boot/dts/imx6q.dtsi:
gpmi-nand@00112000 {
compatible = "fsl,imx6q-gpmi-nand";
...
clocks = <&clks 152>, <&clks 153>, <&clks 151>,
<&clks 150>, <&clks 149>;
clock-names = "gpmi_io", "gpmi_apb", "gpmi_bch",
"gpmi_bch_apb", "per1_bch";
> The motivation for this is to allow registration of the SDHI
> device of the KZM-A9-GT board through device tree.
>
> The following device tree snippet illustrates the use of the bindings
> described above.
>
> sdhi0@0xee100000 {
> compatible = "renesas,shmobile-sdhi";
> reg = <0xee100000 0x100>;
> interrupt-parent = <&gic>;
> interrupts = <0 83 0x4
> 0 84 0x4
> 0 85 0x4>;
> interrupt-names = "card_detect", "sdcard", "sdio";
> reg-io-width = <2>;
> vmmc-supply = <&fixedregulator2v8>;
> vqmmc-supply = <&fixedregulator2v8>;
> renesas,shmobile-sdhi-has-idle-wait;
> };
>
> sdhi2@0xee140000 {
> compatible = "renesas,shmobile-sdhi";
> reg = <0xee140000 0x100>;
> interrupt-parent = <&gic>;
> interrupts = <0 103 0x4
> 0 104 0x4
> 0 105 0x4>;
> interrupt-names = "card_detect", "sdcard", "sdio";
> reg-io-width = <2>;
> vmmc-supply = <&fixedregulator2v8>;
> vqmmc-supply = <&fixedregulator2v8>;
> renesas,shmobile-sdhi-has-idle-wait;
> renesas,shmobile-sdhi-use-gpio-cd;
> renesas,shmobile-sdhi-wrprotect-disable;
> cd-gpios = <&gpio 13 1>;
> };
>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> drivers/mmc/host/sh_mobile_sdhi.c | 76 +++++++++++++++++++++++++++++++------
> 1 file changed, 65 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
> index 0bdc146..8c7e658 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -29,6 +29,7 @@
> #include <linux/mfd/tmio.h>
> #include <linux/sh_dma.h>
> #include <linux/delay.h>
> +#include <linux/of_gpio.h>
>
> #include "tmio_mmc.h"
>
> @@ -117,13 +118,64 @@ static const struct sh_mobile_sdhi_ops sdhi_ops = {
> .cd_wakeup = sh_mobile_sdhi_cd_wakeup,
> };
>
> +static int __devinit
__devinit is being removed:
http://thread.gmane.org/gmane.linux.ports.arm.omap/89686
please, drop it from this patch.
> +sh_mobile_sdhi_probe_clk(struct platform_device *pdev,
> + struct sh_mobile_sdhi *priv,
> + const char *clk_name)
> +{
Once you resolve the doubt about the clock name, maybe this function could
be dropped and you could just call clk_get() directly? Preferably from
sh_mobile_sdhi_probe() directly (also see below)?
> + priv->clk = clk_get(&pdev->dev, clk_name);
> + if (IS_ERR(priv->clk)) {
> + dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> + return PTR_ERR(priv->clk);
> + }
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static int __devinit
> +sh_mobile_sdhi_probe_config_dt(struct platform_device *pdev,
> + struct sh_mobile_sdhi *priv)
> +{
> + struct tmio_mmc_data *mmc_data = &priv->mmc_data;
> + struct device_node *np = pdev->dev.of_node;
> + int ret;
> +
> + BUG_ON(!np);
Hm, does this mean, that if you define CONFIG_OF in your kernel and don't
provide platform data the driver will just Oops?...
> +
> + ret = sh_mobile_sdhi_probe_clk(pdev, priv, np->name);
> + if (ret)
> + return ret;
> +
> + ret = of_get_named_gpio(np, "cd-gpios", 0);
> + if (gpio_is_valid(ret))
> + mmc_data->cd_gpio = ret;
> +
> + if (of_get_property(np, "renesas,shmobile-sdhi-has-idle-wait", NULL))
> + mmc_data->flags |= TMIO_MMC_HAS_IDLE_WAIT;
> + if (of_get_property(np, "renesas,shmobile-sdhi-use-gpio-cd", NULL))
> + mmc_data->flags |= TMIO_MMC_USE_GPIO_CD;
> + if (of_get_property(np, "renesas,shmobile-sdhi-wrprotect-disable",
> + NULL))
> + mmc_data->flags |= TMIO_MMC_WRPROTECT_DISABLE;
> +
> + return 0;
> +}
> +#else
> +static int __devinit
> +sh_mobile_sdhi_probe_config_dt(struct platform_device *pdev,
> + struct sh_mobile_sdhi *priv)
> +{
> + return 0;
> +}
> +#endif
> +
> static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
> {
> struct sh_mobile_sdhi *priv;
> struct tmio_mmc_data *mmc_data;
> struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
> struct tmio_mmc_host *host;
> - char clk_name[8];
> int irq, ret, i = 0;
> bool multiplexed_isr = true;
>
> @@ -144,21 +196,17 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
> }
> }
>
> - snprintf(clk_name, sizeof(clk_name), "sdhi%d", pdev->id);
> - priv->clk = clk_get(&pdev->dev, clk_name);
> - if (IS_ERR(priv->clk)) {
> - dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> - ret = PTR_ERR(priv->clk);
> - goto eclkget;
> - }
> -
> mmc_data->clk_enable = sh_mobile_sdhi_clk_enable;
> mmc_data->clk_disable = sh_mobile_sdhi_clk_disable;
> mmc_data->capabilities = MMC_CAP_MMC_HIGHSPEED;
> if (p) {
> + char clk_name[8];
> + snprintf(clk_name, sizeof(clk_name), "sdhi%d", pdev->id);
> + ret = sh_mobile_sdhi_probe_clk(pdev, priv, clk_name);
> + if (ret)
> + goto eclkget;
> +
This breaks the no-DT and no-platform-data case. With this your patch the
clock wouldn't be obtain then.
> mmc_data->flags = p->tmio_flags;
> - if (mmc_data->flags & TMIO_MMC_HAS_IDLE_WAIT)
> - mmc_data->write16_hook = sh_mobile_sdhi_write16_hook;
> mmc_data->ocr_mask = p->tmio_ocr_mask;
> mmc_data->capabilities |= p->tmio_caps;
> mmc_data->capabilities2 |= p->tmio_caps2;
> @@ -176,7 +224,13 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
> priv->dma_priv.alignment_shift = 1; /* 2-byte alignment */
> mmc_data->dma = &priv->dma_priv;
> }
> + } else {
Please, remember, that the driver should be able to work with no platform
data, no DT and CONFIG_OF either defined or not.
> + ret = sh_mobile_sdhi_probe_config_dt(pdev, priv);
> + if (ret)
> + goto eclkget;
> }
> + if (mmc_data->flags & TMIO_MMC_HAS_IDLE_WAIT)
> + mmc_data->write16_hook = sh_mobile_sdhi_write16_hook;
>
> /*
> * All SDHI blocks support 2-byte and larger block sizes in 4-bit
> --
> 1.7.10.4
>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 1/5] backlight: Add GPIO-based backlight driver
From: Jingoo Han @ 2012-11-26 9:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-sh@vger.kernel.org, linux-fbdev@vger.kernel.org, Paul Mundt,
Magnus Damm, Richard Purdie, Kuninori Morimoto, Jingoo Han
In-Reply-To: <1353688515-30458-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
T24gU2F0dXJkYXksIE5vdmVtYmVyIDI0LCAyMDEyIDE6MzUgQU0sIExhdXJlbnQgUGluY2hhcnQg
d3JvdGUNCj4gDQo+IFNpZ25lZC1vZmYtYnk6IExhdXJlbnQgUGluY2hhcnQgPGxhdXJlbnQucGlu
Y2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4NCg0KQ0MnZWQgQW5kcmV3IE1vcnRvbg0KDQpJdCBsb29r
cyBnb29kLiBBbHNvLCBJIHRlc3RlZCB0aGlzIHBhdGNoIHdpdGggU01ESzQyMTAgYm9hcmQuDQpB
Y2tlZC1ieTogSmluZ29vIEhhbiA8amcxLmhhbkBzYW1zdW5nLmNvbT4NCg0KQmVzdCByZWdhcmRz
LA0KSmluZ29vIEhhbg0KDQo+IC0tLQ0KPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZp
ZyAgICAgICAgICB8ICAgIDcgKysNCj4gIGRyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L01ha2VmaWxl
ICAgICAgICAgfCAgICAxICsNCj4gIGRyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dwaW9fYmFja2xp
Z2h0LmMgfCAgMTU4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiAgaW5jbHVkZS92
aWRlby9ncGlvX2JhY2tsaWdodC5oICAgICAgICAgICB8ICAgMjEgKysrKw0KPiAgNCBmaWxlcyBj
aGFuZ2VkLCAxODcgaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkNCj4gIGNyZWF0ZSBtb2Rl
IDEwMDY0NCBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9ncGlvX2JhY2tsaWdodC5jDQo+ICBjcmVh
dGUgbW9kZSAxMDA2NDQgaW5jbHVkZS92aWRlby9ncGlvX2JhY2tsaWdodC5oDQo+IA0KPiBkaWZm
IC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZpZyBiL2RyaXZlcnMvdmlkZW8v
YmFja2xpZ2h0L0tjb25maWcNCj4gaW5kZXggNzY1YTk0NS4uMjU5NDQyZCAxMDA2NDQNCj4gLS0t
IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZpZw0KPiArKysgYi9kcml2ZXJzL3ZpZGVv
L2JhY2tsaWdodC9LY29uZmlnDQo+IEBAIC0zOTAsNiArMzkwLDEzIEBAIGNvbmZpZyBCQUNLTElH
SFRfVFBTNjUyMTcNCj4gIAkgIElmIHlvdSBoYXZlIGEgVGV4YXMgSW5zdHJ1bWVudHMgVFBTNjUy
MTcgc2F5IFkgdG8gZW5hYmxlIHRoZQ0KPiAgCSAgYmFja2xpZ2h0IGRyaXZlci4NCj4gDQo+ICtj
b25maWcgQkFDS0xJR0hUX0dQSU8NCj4gKwl0cmlzdGF0ZSAiR2VuZXJpYyBHUElPIGJhc2VkIEJh
Y2tsaWdodCBEcml2ZXIiDQo+ICsJZGVwZW5kcyBvbiBHRU5FUklDX0dQSU8NCj4gKwloZWxwDQo+
ICsJICBJZiB5b3UgaGF2ZSBhIExDRCBiYWNrbGlnaHQgYWRqdXN0YWJsZSBieSBHUElPLCBzYXkg
WSB0byBlbmFibGUNCj4gKwkgIHRoaXMgZHJpdmVyLg0KPiArDQo+ICBlbmRpZiAjIEJBQ0tMSUdI
VF9DTEFTU19ERVZJQ0UNCj4gDQo+ICBlbmRpZiAjIEJBQ0tMSUdIVF9MQ0RfU1VQUE9SVA0KPiBk
aWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvTWFrZWZpbGUgYi9kcml2ZXJzL3Zp
ZGVvL2JhY2tsaWdodC9NYWtlZmlsZQ0KPiBpbmRleCBlN2NlNzI5Li5lYzkxYzRhIDEwMDY0NA0K
PiAtLS0gYS9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9NYWtlZmlsZQ0KPiArKysgYi9kcml2ZXJz
L3ZpZGVvL2JhY2tsaWdodC9NYWtlZmlsZQ0KPiBAQCAtNDUsMyArNDUsNCBAQCBvYmotJChDT05G
SUdfQkFDS0xJR0hUX1BDRjUwNjMzKQkrPSBwY2Y1MDYzMy1iYWNrbGlnaHQubw0KPiAgb2JqLSQo
Q09ORklHX0JBQ0tMSUdIVF9BQVQyODcwKSArPSBhYXQyODcwX2JsLm8NCj4gIG9iai0kKENPTkZJ
R19CQUNLTElHSFRfT1QyMDApICs9IG90MjAwX2JsLm8NCj4gIG9iai0kKENPTkZJR19CQUNLTElH
SFRfVFBTNjUyMTcpICs9IHRwczY1MjE3X2JsLm8NCj4gK29iai0kKENPTkZJR19CQUNLTElHSFRf
R1BJTykJKz0gZ3Bpb19iYWNrbGlnaHQubw0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9i
YWNrbGlnaHQvZ3Bpb19iYWNrbGlnaHQuYyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dwaW9f
YmFja2xpZ2h0LmMNCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMC4uNWE4
Y2QzNA0KPiAtLS0gL2Rldi9udWxsDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2dw
aW9fYmFja2xpZ2h0LmMNCj4gQEAgLTAsMCArMSwxNTggQEANCj4gKy8qDQo+ICsgKiBncGlvX2Jh
Y2tsaWdodC5jIC0gU2ltcGxlIEdQSU8tY29udHJvbGxlZCBiYWNrbGlnaHQNCj4gKyAqDQo+ICsg
KiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg
YW5kL29yIG1vZGlmeQ0KPiArICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIgYXMNCj4gKyAqIHB1Ymxpc2hlZCBieSB0aGUgRnJl
ZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0KPiArICovDQo+ICsNCj4gKyNpbmNsdWRlIDxsaW51eC9i
YWNrbGlnaHQuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9lcnIuaD4NCj4gKyNpbmNsdWRlIDxsaW51
eC9mYi5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L2dwaW8uaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9p
bml0Lmg+DQo+ICsjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQo+ICsjaW5jbHVkZSA8bGludXgv
bW9kdWxlLmg+DQo+ICsjaW5jbHVkZSA8bGludXgvcGxhdGZvcm1fZGV2aWNlLmg+DQo+ICsjaW5j
bHVkZSA8bGludXgvc2xhYi5oPg0KPiArI2luY2x1ZGUgPHZpZGVvL2dwaW9fYmFja2xpZ2h0Lmg+
DQo+ICsNCj4gK3N0cnVjdCBncGlvX2JhY2tsaWdodCB7DQo+ICsJc3RydWN0IGRldmljZSAqZGV2
Ow0KPiArCXN0cnVjdCBkZXZpY2UgKmZiZGV2Ow0KPiArDQo+ICsJaW50IGdwaW87DQo+ICsJaW50
IGFjdGl2ZTsNCj4gK307DQo+ICsNCj4gK3N0YXRpYyBpbnQgZ3Bpb19iYWNrbGlnaHRfdXBkYXRl
X3N0YXR1cyhzdHJ1Y3QgYmFja2xpZ2h0X2RldmljZSAqYmwpDQo+ICt7DQo+ICsJc3RydWN0IGdw
aW9fYmFja2xpZ2h0ICpnYmwgPSBibF9nZXRfZGF0YShibCk7DQo+ICsJaW50IGJyaWdodG5lc3Mg
PSBibC0+cHJvcHMuYnJpZ2h0bmVzczsNCj4gKw0KPiArCWlmIChibC0+cHJvcHMucG93ZXIgIT0g
RkJfQkxBTktfVU5CTEFOSyB8fA0KPiArCSAgICBibC0+cHJvcHMuZmJfYmxhbmsgIT0gRkJfQkxB
TktfVU5CTEFOSyB8fA0KPiArCSAgICBibC0+cHJvcHMuc3RhdGUgJiAoQkxfQ09SRV9TVVNQRU5E
RUQgfCBCTF9DT1JFX0ZCQkxBTkspKQ0KPiArCQlicmlnaHRuZXNzID0gMDsNCj4gKw0KPiArCWdw
aW9fc2V0X3ZhbHVlKGdibC0+Z3BpbywgYnJpZ2h0bmVzcyA/IGdibC0+YWN0aXZlIDogIWdibC0+
YWN0aXZlKTsNCj4gKw0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgaW50IGdw
aW9fYmFja2xpZ2h0X2dldF9icmlnaHRuZXNzKHN0cnVjdCBiYWNrbGlnaHRfZGV2aWNlICpibCkN
Cj4gK3sNCj4gKwlyZXR1cm4gYmwtPnByb3BzLmJyaWdodG5lc3M7DQo+ICt9DQo+ICsNCj4gK3N0
YXRpYyBpbnQgZ3Bpb19iYWNrbGlnaHRfY2hlY2tfZmIoc3RydWN0IGJhY2tsaWdodF9kZXZpY2Ug
KmJsLA0KPiArCQkJCSAgIHN0cnVjdCBmYl9pbmZvICppbmZvKQ0KPiArew0KPiArCXN0cnVjdCBn
cGlvX2JhY2tsaWdodCAqZ2JsID0gYmxfZ2V0X2RhdGEoYmwpOw0KPiArDQo+ICsJcmV0dXJuIGdi
bC0+ZmJkZXYgPT0gaW5mby0+ZGV2Ow0KPiArfQ0KPiArDQo+ICtzdGF0aWMgY29uc3Qgc3RydWN0
IGJhY2tsaWdodF9vcHMgZ3Bpb19iYWNrbGlnaHRfb3BzID0gew0KPiArCS51cGRhdGVfc3RhdHVz
CT0gZ3Bpb19iYWNrbGlnaHRfdXBkYXRlX3N0YXR1cywNCj4gKwkuZ2V0X2JyaWdodG5lc3MJPSBn
cGlvX2JhY2tsaWdodF9nZXRfYnJpZ2h0bmVzcywNCj4gKwkuY2hlY2tfZmIJPSBncGlvX2JhY2ts
aWdodF9jaGVja19mYiwNCj4gK307DQo+ICsNCj4gKyNpZmRlZiBDT05GSUdfUE0NCj4gK3N0YXRp
YyBpbnQgZ3Bpb19iYWNrbGlnaHRfc3VzcGVuZChzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ICt7DQo+
ICsJc3RydWN0IGJhY2tsaWdodF9kZXZpY2UgKmJsID0gZGV2X2dldF9kcnZkYXRhKGRldik7DQo+
ICsJc3RydWN0IGdwaW9fYmFja2xpZ2h0ICpnYmwgPSBibF9nZXRfZGF0YShibCk7DQo+ICsNCj4g
KwlncGlvX3NldF92YWx1ZShnYmwtPmdwaW8sICFnYmwtPmFjdGl2ZSk7DQo+ICsNCj4gKwlyZXR1
cm4gMDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBncGlvX2JhY2tsaWdodF9yZXN1bWUoc3Ry
dWN0IGRldmljZSAqZGV2KQ0KPiArew0KPiArCXN0cnVjdCBiYWNrbGlnaHRfZGV2aWNlICpibCA9
IGRldl9nZXRfZHJ2ZGF0YShkZXYpOw0KPiArDQo+ICsJYmFja2xpZ2h0X3VwZGF0ZV9zdGF0dXMo
YmwpOw0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgU0lNUExFX0RFVl9QTV9P
UFMoZ3Bpb19iYWNrbGlnaHRfcG1fb3BzLCBncGlvX2JhY2tsaWdodF9zdXNwZW5kLA0KPiArCQkJ
IGdwaW9fYmFja2xpZ2h0X3Jlc3VtZSk7DQo+ICsNCj4gKyNlbmRpZg0KPiArDQo+ICtzdGF0aWMg
aW50IF9fZGV2aW5pdCBncGlvX2JhY2tsaWdodF9wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNl
ICpwZGV2KQ0KPiArew0KPiArCXN0cnVjdCBncGlvX2JhY2tsaWdodF9wbGF0Zm9ybV9kYXRhICpw
ZGF0YSA9IHBkZXYtPmRldi5wbGF0Zm9ybV9kYXRhOw0KPiArCXN0cnVjdCBiYWNrbGlnaHRfcHJv
cGVydGllcyBwcm9wczsNCj4gKwlzdHJ1Y3QgYmFja2xpZ2h0X2RldmljZSAqYmw7DQo+ICsJc3Ry
dWN0IGdwaW9fYmFja2xpZ2h0ICpnYmw7DQo+ICsJaW50IHJldDsNCj4gKw0KPiArCWdibCA9IGRl
dm1fa3phbGxvYygmcGRldi0+ZGV2LCBzaXplb2YoKmdibCksIEdGUF9LRVJORUwpOw0KPiArCWlm
IChnYmwgPT0gTlVMTCkNCj4gKwkJcmV0dXJuIC1FTk9NRU07DQo+ICsNCj4gKwlnYmwtPmRldiA9
ICZwZGV2LT5kZXY7DQo+ICsNCj4gKwlpZiAoIXBkYXRhKSB7DQo+ICsJCWRldl9lcnIoJnBkZXYt
PmRldiwgImZhaWxlZCB0byBmaW5kIHBsYXRmb3JtIGRhdGFcbiIpOw0KPiArCQlyZXR1cm4gLUVO
T0RFVjsNCj4gKwl9DQo+ICsNCj4gKwlnYmwtPmZiZGV2ID0gcGRhdGEtPmZiZGV2Ow0KPiArCWdi
bC0+Z3BpbyA9IHBkYXRhLT5ncGlvOw0KPiArCWdibC0+YWN0aXZlID0gcGRhdGEtPmFjdGl2ZV9s
b3cgPyAwIDogMTsNCj4gKw0KPiArCXJldCA9IGRldm1fZ3Bpb19yZXF1ZXN0X29uZShnYmwtPmRl
diwgZ2JsLT5ncGlvLCBHUElPRl9ESVJfT1VULA0KPiArCQkJCSAgICBwZGF0YS0+bmFtZSk7DQo+
ICsJaWYgKHJldCA8IDApIHsNCj4gKwkJZGV2X2VycigmcGRldi0+ZGV2LCAidW5hYmxlIHRvIHJl
cXVlc3QgR1BJT1xuIik7DQo+ICsJCXJldHVybiByZXQ7DQo+ICsJfQ0KPiArDQo+ICsJbWVtc2V0
KCZwcm9wcywgMCwgc2l6ZW9mKHByb3BzKSk7DQo+ICsJcHJvcHMudHlwZSA9IEJBQ0tMSUdIVF9S
QVc7DQo+ICsJcHJvcHMubWF4X2JyaWdodG5lc3MgPSAxOw0KPiArCWJsID0gYmFja2xpZ2h0X2Rl
dmljZV9yZWdpc3RlcihkZXZfbmFtZSgmcGRldi0+ZGV2KSwgJnBkZXYtPmRldiwgZ2JsLA0KPiAr
CQkJCSAgICAgICAmZ3Bpb19iYWNrbGlnaHRfb3BzLCAmcHJvcHMpOw0KPiArCWlmIChJU19FUlIo
YmwpKSB7DQo+ICsJCWRldl9lcnIoJnBkZXYtPmRldiwgImZhaWxlZCB0byByZWdpc3RlciBiYWNr
bGlnaHRcbiIpOw0KPiArCQlyZXR1cm4gUFRSX0VSUihibCk7DQo+ICsJfQ0KPiArDQo+ICsJYmwt
PnByb3BzLmJyaWdodG5lc3MgPSBwZGF0YS0+ZGVmX3ZhbHVlOw0KPiArCWJhY2tsaWdodF91cGRh
dGVfc3RhdHVzKGJsKTsNCj4gKw0KPiArCXBsYXRmb3JtX3NldF9kcnZkYXRhKHBkZXYsIGJsKTsN
Cj4gKwlyZXR1cm4gMDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBfX2RldmV4aXQgZ3Bpb19i
YWNrbGlnaHRfcmVtb3ZlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ICt7DQo+ICsJ
c3RydWN0IGJhY2tsaWdodF9kZXZpY2UgKmJsID0gcGxhdGZvcm1fZ2V0X2RydmRhdGEocGRldik7
DQo+ICsNCj4gKwliYWNrbGlnaHRfZGV2aWNlX3VucmVnaXN0ZXIoYmwpOw0KPiArCXJldHVybiAw
Ow0KPiArfQ0KPiArDQo+ICtzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBncGlvX2JhY2ts
aWdodF9kcml2ZXIgPSB7DQo+ICsJLmRyaXZlcgkJPSB7DQo+ICsJCS5uYW1lCQk9ICJncGlvLWJh
Y2tsaWdodCIsDQo+ICsJCS5vd25lcgkJPSBUSElTX01PRFVMRSwNCj4gKyNpZmRlZiBDT05GSUdf
UE0NCj4gKwkJLnBtCQk9ICZncGlvX2JhY2tsaWdodF9wbV9vcHMsDQo+ICsjZW5kaWYNCj4gKwl9
LA0KPiArCS5wcm9iZQkJPSBncGlvX2JhY2tsaWdodF9wcm9iZSwNCj4gKwkucmVtb3ZlCQk9IF9f
ZGV2ZXhpdF9wKGdwaW9fYmFja2xpZ2h0X3JlbW92ZSksDQo+ICt9Ow0KPiArDQo+ICttb2R1bGVf
cGxhdGZvcm1fZHJpdmVyKGdwaW9fYmFja2xpZ2h0X2RyaXZlcik7DQo+ICsNCj4gK01PRFVMRV9B
VVRIT1IoIkxhdXJlbnQgUGluY2hhcnQgPGxhdXJlbnQucGluY2hhcnRAaWRlYXNvbmJvYXJkLmNv
bT4iKTsNCj4gK01PRFVMRV9ERVNDUklQVElPTigiR1BJTy1iYXNlZCBCYWNrbGlnaHQgRHJpdmVy
Iik7DQo+ICtNT0RVTEVfTElDRU5TRSgiR1BMIik7DQo+ICtNT0RVTEVfQUxJQVMoInBsYXRmb3Jt
OmdwaW8tYmFja2xpZ2h0Iik7DQo+IGRpZmYgLS1naXQgYS9pbmNsdWRlL3ZpZGVvL2dwaW9fYmFj
a2xpZ2h0LmggYi9pbmNsdWRlL3ZpZGVvL2dwaW9fYmFja2xpZ2h0LmgNCj4gbmV3IGZpbGUgbW9k
ZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMC4uNWFlMGQ5Yw0KPiAtLS0gL2Rldi9udWxsDQo+ICsr
KyBiL2luY2x1ZGUvdmlkZW8vZ3Bpb19iYWNrbGlnaHQuaA0KPiBAQCAtMCwwICsxLDIxIEBADQo+
ICsvKg0KPiArICogZ3Bpb19iYWNrbGlnaHQuaCAtIFNpbXBsZSBHUElPLWNvbnRyb2xsZWQgYmFj
a2xpZ2h0DQo+ICsgKg0KPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBj
YW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkNCj4gKyAqIGl0IHVuZGVyIHRoZSB0ZXJt
cyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzDQo+ICsgKiBw
dWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCj4gKyAqLw0KPiArI2lm
bmRlZiBfX0dQSU9fQkFDS0xJR0hUX0hfXw0KPiArI2RlZmluZSBfX0dQSU9fQkFDS0xJR0hUX0hf
Xw0KPiArDQo+ICtzdHJ1Y3QgZGV2aWNlOw0KPiArDQo+ICtzdHJ1Y3QgZ3Bpb19iYWNrbGlnaHRf
cGxhdGZvcm1fZGF0YSB7DQo+ICsJc3RydWN0IGRldmljZSAqZmJkZXY7DQo+ICsJaW50IGdwaW87
DQo+ICsJaW50IGRlZl92YWx1ZTsNCj4gKwlib29sIGFjdGl2ZV9sb3c7DQo+ICsJY29uc3QgY2hh
ciAqbmFtZTsNCj4gK307DQo+ICsNCj4gKyNlbmRpZg0KPiAtLQ0KPiAxLjcuOC42DQo+IA0KPiAt
LQ0KPiBUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJz
Y3JpYmUgbGludXgtZmJkZXYiIGluDQo+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRv
bW9Admdlci5rZXJuZWwub3JnDQo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2Vy
Lmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0K
^ permalink raw reply
* Re: [PATCH 2/5] backlight: Add Sanyo LV5207LP backlight driver
From: Jingoo Han @ 2012-11-26 9:48 UTC (permalink / raw)
To: Laurent Pinchart
Cc: akpm, linux-kernel, linux-sh@vger.kernel.org,
linux-fbdev@vger.kernel.org, Paul Mundt, Magnus Damm,
Richard Purdie, Kuninori Morimoto, Jingoo Han
In-Reply-To: <1353688515-30458-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
T24gU2F0dXJkYXksIE5vdmVtYmVyIDI0LCAyMDEyIDE6MzUgQU0sIExhdXJlbnQgUGluY2hhcnQg
d3JvdGUNCj4gDQo+IFNpZ25lZC1vZmYtYnk6IExhdXJlbnQgUGluY2hhcnQgPGxhdXJlbnQucGlu
Y2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4NCg0KQ0MnZWQgQW5kcmV3IE1vcnRvbg0KDQpBY2tlZC1i
eTogSmluZ29vIEhhbiA8amcxLmhhbkBzYW1zdW5nLmNvbT4NCg0KQmVzdCByZWdhcmRzLA0KSmlu
Z29vIEhhbg0KDQo+IC0tLQ0KPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQvS2NvbmZpZyAgICAg
ICAgfCAgICA2ICsNCj4gIGRyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L01ha2VmaWxlICAgICAgIHwg
ICAgMSArDQo+ICBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9sdjUyMDdscC5jICAgICB8ICAxNzEg
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gIGluY2x1ZGUvbGludXgvcGxhdGZv
cm1fZGF0YS9sdjUyMDdscC5oIHwgICAyMCArKysrDQo+ICA0IGZpbGVzIGNoYW5nZWQsIDE5OCBp
bnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQ0KPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZl
cnMvdmlkZW8vYmFja2xpZ2h0L2x2NTIwN2xwLmMNCj4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNs
dWRlL2xpbnV4L3BsYXRmb3JtX2RhdGEvbHY1MjA3bHAuaA0KPiANCj4gZGlmZiAtLWdpdCBhL2Ry
aXZlcnMvdmlkZW8vYmFja2xpZ2h0L0tjb25maWcgYi9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9L
Y29uZmlnDQo+IGluZGV4IDI1OTQ0MmQuLjkyY2U1YWEgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMv
dmlkZW8vYmFja2xpZ2h0L0tjb25maWcNCj4gKysrIGIvZHJpdmVycy92aWRlby9iYWNrbGlnaHQv
S2NvbmZpZw0KPiBAQCAtMzk3LDYgKzM5NywxMiBAQCBjb25maWcgQkFDS0xJR0hUX0dQSU8NCj4g
IAkgIElmIHlvdSBoYXZlIGEgTENEIGJhY2tsaWdodCBhZGp1c3RhYmxlIGJ5IEdQSU8sIHNheSBZ
IHRvIGVuYWJsZQ0KPiAgCSAgdGhpcyBkcml2ZXIuDQo+IA0KPiArY29uZmlnIEJBQ0tMSUdIVF9M
VjUyMDdMUA0KPiArCXRyaXN0YXRlICJTYW55byBMVjUyMDdMUCBCYWNrbGlnaHQiDQo+ICsJZGVw
ZW5kcyBvbiBJMkMNCj4gKwloZWxwDQo+ICsJICBJZiB5b3UgaGF2ZSBhIFNhbnlvIExWNTIwN0xQ
IHNheSBZIHRvIGVuYWJsZSB0aGUgYmFja2xpZ2h0IGRyaXZlci4NCj4gKw0KPiAgZW5kaWYgIyBC
QUNLTElHSFRfQ0xBU1NfREVWSUNFDQo+IA0KPiAgZW5kaWYgIyBCQUNLTElHSFRfTENEX1NVUFBP
UlQNCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L01ha2VmaWxlIGIvZHJp
dmVycy92aWRlby9iYWNrbGlnaHQvTWFrZWZpbGUNCj4gaW5kZXggZWM5MWM0YS4uMTI1YjhhZCAx
MDA2NDQNCj4gLS0tIGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvTWFrZWZpbGUNCj4gKysrIGIv
ZHJpdmVycy92aWRlby9iYWNrbGlnaHQvTWFrZWZpbGUNCj4gQEAgLTQ2LDMgKzQ2LDQgQEAgb2Jq
LSQoQ09ORklHX0JBQ0tMSUdIVF9BQVQyODcwKSArPSBhYXQyODcwX2JsLm8NCj4gIG9iai0kKENP
TkZJR19CQUNLTElHSFRfT1QyMDApICs9IG90MjAwX2JsLm8NCj4gIG9iai0kKENPTkZJR19CQUNL
TElHSFRfVFBTNjUyMTcpICs9IHRwczY1MjE3X2JsLm8NCj4gIG9iai0kKENPTkZJR19CQUNLTElH
SFRfR1BJTykJKz0gZ3Bpb19iYWNrbGlnaHQubw0KPiArb2JqLSQoQ09ORklHX0JBQ0tMSUdIVF9M
VjUyMDdMUCkJKz0gbHY1MjA3bHAubw0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNr
bGlnaHQvbHY1MjA3bHAuYyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2x2NTIwN2xwLmMNCj4g
bmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMC4uYjA2ZjM1Yw0KPiAtLS0gL2Rl
di9udWxsDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L2x2NTIwN2xwLmMNCj4gQEAg
LTAsMCArMSwxNzEgQEANCj4gKy8qDQo+ICsgKiBTYW55byBMVjUyMDdMUCBMRUQgRHJpdmVyDQo+
ICsgKg0KPiArICogQ29weXJpZ2h0IChDKSAyMDEyIElkZWFzIG9uIGJvYXJkIFNQUkwNCj4gKyAq
DQo+ICsgKiBDb250YWN0OiBMYXVyZW50IFBpbmNoYXJ0IDxsYXVyZW50LnBpbmNoYXJ0QGlkZWFz
b25ib2FyZC5jb20+DQo+ICsgKg0KPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7
IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkNCj4gKyAqIGl0IHVuZGVyIHRo
ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzDQo+
ICsgKiBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCj4gKyAqLw0K
PiArDQo+ICsjaW5jbHVkZSA8bGludXgvYmFja2xpZ2h0Lmg+DQo+ICsjaW5jbHVkZSA8bGludXgv
ZXJyLmg+DQo+ICsjaW5jbHVkZSA8bGludXgvZmIuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9pMmMu
aD4NCj4gKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9zbGFi
Lmg+DQo+ICsjaW5jbHVkZSA8bGludXgvcGxhdGZvcm1fZGF0YS9sdjUyMDdscC5oPg0KPiArDQo+
ICsjZGVmaW5lIExWNTIwN0xQX0NUUkwxCQkJMHgwMA0KPiArI2RlZmluZSBMVjUyMDdMUF9DUFNX
CQkJKDEgPDwgNykNCj4gKyNkZWZpbmUgTFY1MjA3TFBfU0NURU4JCQkoMSA8PCA2KQ0KPiArI2Rl
ZmluZSBMVjUyMDdMUF9DMTAJCQkoMSA8PCA1KQ0KPiArI2RlZmluZSBMVjUyMDdMUF9DS1NXCQkJ
KDEgPDwgNCkNCj4gKyNkZWZpbmUgTFY1MjA3TFBfUlNXCQkJKDEgPDwgMykNCj4gKyNkZWZpbmUg
TFY1MjA3TFBfR1NXCQkJKDEgPDwgMikNCj4gKyNkZWZpbmUgTFY1MjA3TFBfQlNXCQkJKDEgPDwg
MSkNCj4gKyNkZWZpbmUgTFY1MjA3TFBfQ1RSTDIJCQkweDAxDQo+ICsjZGVmaW5lIExWNTIwN0xQ
X01TVwkJCSgxIDw8IDcpDQo+ICsjZGVmaW5lIExWNTIwN0xQX01MRUQ0CQkJKDEgPDwgNikNCj4g
KyNkZWZpbmUgTFY1MjA3TFBfUkVECQkJMHgwMg0KPiArI2RlZmluZSBMVjUyMDdMUF9HUkVFTgkJ
CTB4MDMNCj4gKyNkZWZpbmUgTFY1MjA3TFBfQkxVRQkJCTB4MDQNCj4gKw0KPiArI2RlZmluZSBM
VjUyMDdMUF9NQVhfQlJJR0hUTkVTUwkJMzINCj4gKw0KPiArc3RydWN0IGx2NTIwN2xwIHsNCj4g
KwlzdHJ1Y3QgaTJjX2NsaWVudCAqY2xpZW50Ow0KPiArCXN0cnVjdCBiYWNrbGlnaHRfZGV2aWNl
ICpiYWNrbGlnaHQ7DQo+ICsJc3RydWN0IGx2NTIwN2xwX3BsYXRmb3JtX2RhdGEgKnBkYXRhOw0K
PiArfTsNCj4gKw0KPiArc3RhdGljIGludCBsdjUyMDdscF93cml0ZShzdHJ1Y3QgbHY1MjA3bHAg
Kmx2LCB1OCByZWcsIHU4IGRhdGEpDQo+ICt7DQo+ICsJcmV0dXJuIGkyY19zbWJ1c193cml0ZV9i
eXRlX2RhdGEobHYtPmNsaWVudCwgcmVnLCBkYXRhKTsNCj4gK30NCj4gKw0KPiArc3RhdGljIGlu
dCBsdjUyMDdscF9iYWNrbGlnaHRfdXBkYXRlX3N0YXR1cyhzdHJ1Y3QgYmFja2xpZ2h0X2Rldmlj
ZSAqYmFja2xpZ2h0KQ0KPiArew0KPiArCXN0cnVjdCBsdjUyMDdscCAqbHYgPSBibF9nZXRfZGF0
YShiYWNrbGlnaHQpOw0KPiArCWludCBicmlnaHRuZXNzID0gYmFja2xpZ2h0LT5wcm9wcy5icmln
aHRuZXNzOw0KPiArDQo+ICsJaWYgKGJhY2tsaWdodC0+cHJvcHMucG93ZXIgIT0gRkJfQkxBTktf
VU5CTEFOSyB8fA0KPiArCSAgICBiYWNrbGlnaHQtPnByb3BzLmZiX2JsYW5rICE9IEZCX0JMQU5L
X1VOQkxBTksgfHwNCj4gKwkgICAgYmFja2xpZ2h0LT5wcm9wcy5zdGF0ZSAmIChCTF9DT1JFX1NV
U1BFTkRFRCB8IEJMX0NPUkVfRkJCTEFOSykpDQo+ICsJCWJyaWdodG5lc3MgPSAwOw0KPiArDQo+
ICsJaWYgKGJyaWdodG5lc3MpIHsNCj4gKwkJbHY1MjA3bHBfd3JpdGUobHYsIExWNTIwN0xQX0NU
UkwxLA0KPiArCQkJICAgICAgIExWNTIwN0xQX0NQU1cgfCBMVjUyMDdMUF9DMTAgfCBMVjUyMDdM
UF9DS1NXKTsNCj4gKwkJbHY1MjA3bHBfd3JpdGUobHYsIExWNTIwN0xQX0NUUkwyLA0KPiArCQkJ
ICAgICAgIExWNTIwN0xQX01TVyB8IExWNTIwN0xQX01MRUQ0IHwNCj4gKwkJCSAgICAgICAoYnJp
Z2h0bmVzcyAtIDEpKTsNCj4gKwl9IGVsc2Ugew0KPiArCQlsdjUyMDdscF93cml0ZShsdiwgTFY1
MjA3TFBfQ1RSTDEsIDApOw0KPiArCQlsdjUyMDdscF93cml0ZShsdiwgTFY1MjA3TFBfQ1RSTDIs
IDApOw0KPiArCX0NCj4gKw0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgaW50
IGx2NTIwN2xwX2JhY2tsaWdodF9nZXRfYnJpZ2h0bmVzcyhzdHJ1Y3QgYmFja2xpZ2h0X2Rldmlj
ZSAqYmFja2xpZ2h0KQ0KPiArew0KPiArCXJldHVybiBiYWNrbGlnaHQtPnByb3BzLmJyaWdodG5l
c3M7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyBpbnQgbHY1MjA3bHBfYmFja2xpZ2h0X2NoZWNrX2Zi
KHN0cnVjdCBiYWNrbGlnaHRfZGV2aWNlICpiYWNrbGlnaHQsDQo+ICsJCQkJICAgICAgIHN0cnVj
dCBmYl9pbmZvICppbmZvKQ0KPiArew0KPiArCXN0cnVjdCBsdjUyMDdscCAqbHYgPSBibF9nZXRf
ZGF0YShiYWNrbGlnaHQpOw0KPiArDQo+ICsJcmV0dXJuIGx2LT5wZGF0YS0+ZmJkZXYgPT0gaW5m
by0+ZGV2Ow0KPiArfQ0KPiArDQo+ICtzdGF0aWMgY29uc3Qgc3RydWN0IGJhY2tsaWdodF9vcHMg
bHY1MjA3bHBfYmFja2xpZ2h0X29wcyA9IHsNCj4gKwkub3B0aW9ucwk9IEJMX0NPUkVfU1VTUEVO
RFJFU1VNRSwNCj4gKwkudXBkYXRlX3N0YXR1cwk9IGx2NTIwN2xwX2JhY2tsaWdodF91cGRhdGVf
c3RhdHVzLA0KPiArCS5nZXRfYnJpZ2h0bmVzcwk9IGx2NTIwN2xwX2JhY2tsaWdodF9nZXRfYnJp
Z2h0bmVzcywNCj4gKwkuY2hlY2tfZmIJPSBsdjUyMDdscF9iYWNrbGlnaHRfY2hlY2tfZmIsDQo+
ICt9Ow0KPiArDQo+ICtzdGF0aWMgaW50IGx2NTIwN2xwX3Byb2JlKHN0cnVjdCBpMmNfY2xpZW50
ICpjbGllbnQsDQo+ICsJCQkgIGNvbnN0IHN0cnVjdCBpMmNfZGV2aWNlX2lkICppZCkNCj4gK3sN
Cj4gKwlzdHJ1Y3QgbHY1MjA3bHBfcGxhdGZvcm1fZGF0YSAqcGRhdGEgPSBjbGllbnQtPmRldi5w
bGF0Zm9ybV9kYXRhOw0KPiArCXN0cnVjdCBiYWNrbGlnaHRfZGV2aWNlICpiYWNrbGlnaHQ7DQo+
ICsJc3RydWN0IGJhY2tsaWdodF9wcm9wZXJ0aWVzIHByb3BzOw0KPiArCXN0cnVjdCBsdjUyMDds
cCAqbHY7DQo+ICsNCj4gKwlpZiAocGRhdGEgPT0gTlVMTCkgew0KPiArCQlkZXZfZXJyKCZjbGll
bnQtPmRldiwgIk5vIHBsYXRmb3JtIGRhdGEgc3VwcGxpZWRcbiIpOw0KPiArCQlyZXR1cm4gLUVJ
TlZBTDsNCj4gKwl9DQo+ICsNCj4gKwlpZiAoIWkyY19jaGVja19mdW5jdGlvbmFsaXR5KGNsaWVu
dC0+YWRhcHRlciwNCj4gKwkJCQkgICAgIEkyQ19GVU5DX1NNQlVTX0JZVEVfREFUQSkpIHsNCj4g
KwkJZGV2X3dhcm4oJmNsaWVudC0+ZGV2LA0KPiArCQkJICJJMkMgYWRhcHRlciBkb2Vzbid0IHN1
cHBvcnQgSTJDX0ZVTkNfU01CVVNfQllURVxuIik7DQo+ICsJCXJldHVybiAtRUlPOw0KPiArCX0N
Cj4gKw0KPiArCWx2ID0gZGV2bV9remFsbG9jKCZjbGllbnQtPmRldiwgc2l6ZW9mKCpsdiksIEdG
UF9LRVJORUwpOw0KPiArCWlmICghbHYpDQo+ICsJCXJldHVybiAtRU5PTUVNOw0KPiArDQo+ICsJ
bHYtPmNsaWVudCA9IGNsaWVudDsNCj4gKwlsdi0+cGRhdGEgPSBwZGF0YTsNCj4gKw0KPiArCW1l
bXNldCgmcHJvcHMsIDAsIHNpemVvZihwcm9wcykpOw0KPiArCXByb3BzLnR5cGUgPSBCQUNLTElH
SFRfUkFXOw0KPiArCXByb3BzLm1heF9icmlnaHRuZXNzID0gbWluX3QodW5zaWduZWQgaW50LCBw
ZGF0YS0+bWF4X3ZhbHVlLA0KPiArCQkJCSAgICAgTFY1MjA3TFBfTUFYX0JSSUdIVE5FU1MpOw0K
PiArCXByb3BzLmJyaWdodG5lc3MgPSBjbGFtcF90KHVuc2lnbmVkIGludCwgcGRhdGEtPmRlZl92
YWx1ZSwgMCwNCj4gKwkJCQkgICBwcm9wcy5tYXhfYnJpZ2h0bmVzcyk7DQo+ICsNCj4gKwliYWNr
bGlnaHQgPSBiYWNrbGlnaHRfZGV2aWNlX3JlZ2lzdGVyKGRldl9uYW1lKCZjbGllbnQtPmRldiks
DQo+ICsJCQkJCSAgICAgICZsdi0+Y2xpZW50LT5kZXYsIGx2LA0KPiArCQkJCQkgICAgICAmbHY1
MjA3bHBfYmFja2xpZ2h0X29wcywgJnByb3BzKTsNCj4gKwlpZiAoSVNfRVJSKGJhY2tsaWdodCkp
IHsNCj4gKwkJZGV2X2VycigmY2xpZW50LT5kZXYsICJmYWlsZWQgdG8gcmVnaXN0ZXIgYmFja2xp
Z2h0XG4iKTsNCj4gKwkJcmV0dXJuIFBUUl9FUlIoYmFja2xpZ2h0KTsNCj4gKwl9DQo+ICsNCj4g
KwliYWNrbGlnaHRfdXBkYXRlX3N0YXR1cyhiYWNrbGlnaHQpOw0KPiArCWkyY19zZXRfY2xpZW50
ZGF0YShjbGllbnQsIGJhY2tsaWdodCk7DQo+ICsNCj4gKwlyZXR1cm4gMDsNCj4gK30NCj4gKw0K
PiArc3RhdGljIGludCBsdjUyMDdscF9yZW1vdmUoc3RydWN0IGkyY19jbGllbnQgKmNsaWVudCkN
Cj4gK3sNCj4gKwlzdHJ1Y3QgYmFja2xpZ2h0X2RldmljZSAqYmFja2xpZ2h0ID0gaTJjX2dldF9j
bGllbnRkYXRhKGNsaWVudCk7DQo+ICsNCj4gKwliYWNrbGlnaHQtPnByb3BzLmJyaWdodG5lc3Mg
PSAwOw0KPiArCWJhY2tsaWdodF91cGRhdGVfc3RhdHVzKGJhY2tsaWdodCk7DQo+ICsJYmFja2xp
Z2h0X2RldmljZV91bnJlZ2lzdGVyKGJhY2tsaWdodCk7DQo+ICsNCj4gKwlyZXR1cm4gMDsNCj4g
K30NCj4gKw0KPiArc3RhdGljIGNvbnN0IHN0cnVjdCBpMmNfZGV2aWNlX2lkIGx2NTIwN2xwX2lk
c1tdID0gew0KPiArCXsgImx2NTIwN2xwIiwgMCB9LA0KPiArCXsgfQ0KPiArfTsNCj4gK01PRFVM
RV9ERVZJQ0VfVEFCTEUoaTJjLCBsdjUyMDdscF9pZHMpOw0KPiArDQo+ICtzdGF0aWMgc3RydWN0
IGkyY19kcml2ZXIgbHY1MjA3bHBfZHJpdmVyID0gew0KPiArCS5kcml2ZXIgPSB7DQo+ICsJCS5u
YW1lID0gImx2NTIwN2xwIiwNCj4gKwl9LA0KPiArCS5wcm9iZSA9IGx2NTIwN2xwX3Byb2JlLA0K
PiArCS5yZW1vdmUgPSBsdjUyMDdscF9yZW1vdmUsDQo+ICsJLmlkX3RhYmxlID0gbHY1MjA3bHBf
aWRzLA0KPiArfTsNCj4gKw0KPiArbW9kdWxlX2kyY19kcml2ZXIobHY1MjA3bHBfZHJpdmVyKTsN
Cj4gKw0KPiArTU9EVUxFX0RFU0NSSVBUSU9OKCJTYW55byBMVjUyMDdMUCBCYWNrbGlnaHQgRHJp
dmVyIik7DQo+ICtNT0RVTEVfQVVUSE9SKCJMYXVyZW50IFBpbmNoYXJ0IDxsYXVyZW50LnBpbmNo
YXJ0QGlkZWFzb25ib2FyZC5jb20+Iik7DQo+ICtNT0RVTEVfTElDRU5TRSgiR1BMIik7DQo+IGRp
ZmYgLS1naXQgYS9pbmNsdWRlL2xpbnV4L3BsYXRmb3JtX2RhdGEvbHY1MjA3bHAuaCBiL2luY2x1
ZGUvbGludXgvcGxhdGZvcm1fZGF0YS9sdjUyMDdscC5oDQo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0
DQo+IGluZGV4IDAwMDAwMDAuLmFjOTVjYjENCj4gLS0tIC9kZXYvbnVsbA0KPiArKysgYi9pbmNs
dWRlL2xpbnV4L3BsYXRmb3JtX2RhdGEvbHY1MjA3bHAuaA0KPiBAQCAtMCwwICsxLDIwIEBADQo+
ICsvKg0KPiArICogbHY1MjA3bHAuaCAtIFNhbnlvIExWNTIwN0xQIExFRHMgRHJpdmVyDQo+ICsg
Kg0KPiArICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlIGl0IGFuZC9vciBtb2RpZnkNCj4gKyAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVyc2lvbiAyIGFzDQo+ICsgKiBwdWJsaXNoZWQgYnkg
dGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4NCj4gKyAqLw0KPiArI2lmbmRlZiBfX0xWNTIw
N0xQX0hfXw0KPiArI2RlZmluZSBfX0xWNTIwN0xQX0hfXw0KPiArDQo+ICtzdHJ1Y3QgZGV2aWNl
Ow0KPiArDQo+ICtzdHJ1Y3QgbHY1MjA3bHBfcGxhdGZvcm1fZGF0YSB7DQo+ICsJc3RydWN0IGRl
dmljZSAqZmJkZXY7DQo+ICsJdW5zaWduZWQgaW50IG1heF92YWx1ZTsNCj4gKwl1bnNpZ25lZCBp
bnQgZGVmX3ZhbHVlOw0KPiArfTsNCj4gKw0KPiArI2VuZGlmDQo+ICsNCj4gLS0NCj4gMS43Ljgu
Ng0KPiANCj4gLS0NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxp
bmUgInVuc3Vic2NyaWJlIGxpbnV4LWZiZGV2IiBpbg0KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2Ug
dG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBo
dHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwNCg=
^ permalink raw reply
* Re: [PATCH 2/5] backlight: Add Sanyo LV5207LP backlight driver
From: Jingoo Han @ 2012-11-26 9:38 UTC (permalink / raw)
To: 'Laurent Pinchart'
Cc: 'Andrew Morton', 'LKML', linux-sh, linux-fbdev,
'Paul Mundt', 'Magnus Damm',
'Richard Purdie', 'Kuninori Morimoto',
'Jingoo Han'
In-Reply-To: <1353688515-30458-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Saturday, November 24, 2012 1:35 AM, Laurent Pinchart wrote
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
CC'ed Andrew Morton
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/backlight/Kconfig | 6 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/lv5207lp.c | 171 ++++++++++++++++++++++++++++++++
> include/linux/platform_data/lv5207lp.h | 20 ++++
> 4 files changed, 198 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/backlight/lv5207lp.c
> create mode 100644 include/linux/platform_data/lv5207lp.h
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 259442d..92ce5aa 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -397,6 +397,12 @@ config BACKLIGHT_GPIO
> If you have a LCD backlight adjustable by GPIO, say Y to enable
> this driver.
>
> +config BACKLIGHT_LV5207LP
> + tristate "Sanyo LV5207LP Backlight"
> + depends on I2C
> + help
> + If you have a Sanyo LV5207LP say Y to enable the backlight driver.
> +
> endif # BACKLIGHT_CLASS_DEVICE
>
> endif # BACKLIGHT_LCD_SUPPORT
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index ec91c4a..125b8ad 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -46,3 +46,4 @@ obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
> obj-$(CONFIG_BACKLIGHT_GPIO) += gpio_backlight.o
> +obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
> diff --git a/drivers/video/backlight/lv5207lp.c b/drivers/video/backlight/lv5207lp.c
> new file mode 100644
> index 0000000..b06f35c
> --- /dev/null
> +++ b/drivers/video/backlight/lv5207lp.c
> @@ -0,0 +1,171 @@
> +/*
> + * Sanyo LV5207LP LED Driver
> + *
> + * Copyright (C) 2012 Ideas on board SPRL
> + *
> + * Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/err.h>
> +#include <linux/fb.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/platform_data/lv5207lp.h>
> +
> +#define LV5207LP_CTRL1 0x00
> +#define LV5207LP_CPSW (1 << 7)
> +#define LV5207LP_SCTEN (1 << 6)
> +#define LV5207LP_C10 (1 << 5)
> +#define LV5207LP_CKSW (1 << 4)
> +#define LV5207LP_RSW (1 << 3)
> +#define LV5207LP_GSW (1 << 2)
> +#define LV5207LP_BSW (1 << 1)
> +#define LV5207LP_CTRL2 0x01
> +#define LV5207LP_MSW (1 << 7)
> +#define LV5207LP_MLED4 (1 << 6)
> +#define LV5207LP_RED 0x02
> +#define LV5207LP_GREEN 0x03
> +#define LV5207LP_BLUE 0x04
> +
> +#define LV5207LP_MAX_BRIGHTNESS 32
> +
> +struct lv5207lp {
> + struct i2c_client *client;
> + struct backlight_device *backlight;
> + struct lv5207lp_platform_data *pdata;
> +};
> +
> +static int lv5207lp_write(struct lv5207lp *lv, u8 reg, u8 data)
> +{
> + return i2c_smbus_write_byte_data(lv->client, reg, data);
> +}
> +
> +static int lv5207lp_backlight_update_status(struct backlight_device *backlight)
> +{
> + struct lv5207lp *lv = bl_get_data(backlight);
> + int brightness = backlight->props.brightness;
> +
> + if (backlight->props.power != FB_BLANK_UNBLANK ||
> + backlight->props.fb_blank != FB_BLANK_UNBLANK ||
> + backlight->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> + brightness = 0;
> +
> + if (brightness) {
> + lv5207lp_write(lv, LV5207LP_CTRL1,
> + LV5207LP_CPSW | LV5207LP_C10 | LV5207LP_CKSW);
> + lv5207lp_write(lv, LV5207LP_CTRL2,
> + LV5207LP_MSW | LV5207LP_MLED4 |
> + (brightness - 1));
> + } else {
> + lv5207lp_write(lv, LV5207LP_CTRL1, 0);
> + lv5207lp_write(lv, LV5207LP_CTRL2, 0);
> + }
> +
> + return 0;
> +}
> +
> +static int lv5207lp_backlight_get_brightness(struct backlight_device *backlight)
> +{
> + return backlight->props.brightness;
> +}
> +
> +static int lv5207lp_backlight_check_fb(struct backlight_device *backlight,
> + struct fb_info *info)
> +{
> + struct lv5207lp *lv = bl_get_data(backlight);
> +
> + return lv->pdata->fbdev = info->dev;
> +}
> +
> +static const struct backlight_ops lv5207lp_backlight_ops = {
> + .options = BL_CORE_SUSPENDRESUME,
> + .update_status = lv5207lp_backlight_update_status,
> + .get_brightness = lv5207lp_backlight_get_brightness,
> + .check_fb = lv5207lp_backlight_check_fb,
> +};
> +
> +static int lv5207lp_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct lv5207lp_platform_data *pdata = client->dev.platform_data;
> + struct backlight_device *backlight;
> + struct backlight_properties props;
> + struct lv5207lp *lv;
> +
> + if (pdata = NULL) {
> + dev_err(&client->dev, "No platform data supplied\n");
> + return -EINVAL;
> + }
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_BYTE_DATA)) {
> + dev_warn(&client->dev,
> + "I2C adapter doesn't support I2C_FUNC_SMBUS_BYTE\n");
> + return -EIO;
> + }
> +
> + lv = devm_kzalloc(&client->dev, sizeof(*lv), GFP_KERNEL);
> + if (!lv)
> + return -ENOMEM;
> +
> + lv->client = client;
> + lv->pdata = pdata;
> +
> + memset(&props, 0, sizeof(props));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = min_t(unsigned int, pdata->max_value,
> + LV5207LP_MAX_BRIGHTNESS);
> + props.brightness = clamp_t(unsigned int, pdata->def_value, 0,
> + props.max_brightness);
> +
> + backlight = backlight_device_register(dev_name(&client->dev),
> + &lv->client->dev, lv,
> + &lv5207lp_backlight_ops, &props);
> + if (IS_ERR(backlight)) {
> + dev_err(&client->dev, "failed to register backlight\n");
> + return PTR_ERR(backlight);
> + }
> +
> + backlight_update_status(backlight);
> + i2c_set_clientdata(client, backlight);
> +
> + return 0;
> +}
> +
> +static int lv5207lp_remove(struct i2c_client *client)
> +{
> + struct backlight_device *backlight = i2c_get_clientdata(client);
> +
> + backlight->props.brightness = 0;
> + backlight_update_status(backlight);
> + backlight_device_unregister(backlight);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id lv5207lp_ids[] = {
> + { "lv5207lp", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, lv5207lp_ids);
> +
> +static struct i2c_driver lv5207lp_driver = {
> + .driver = {
> + .name = "lv5207lp",
> + },
> + .probe = lv5207lp_probe,
> + .remove = lv5207lp_remove,
> + .id_table = lv5207lp_ids,
> +};
> +
> +module_i2c_driver(lv5207lp_driver);
> +
> +MODULE_DESCRIPTION("Sanyo LV5207LP Backlight Driver");
> +MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart@ideasonboard.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/platform_data/lv5207lp.h b/include/linux/platform_data/lv5207lp.h
> new file mode 100644
> index 0000000..ac95cb1
> --- /dev/null
> +++ b/include/linux/platform_data/lv5207lp.h
> @@ -0,0 +1,20 @@
> +/*
> + * lv5207lp.h - Sanyo LV5207LP LEDs Driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LV5207LP_H__
> +#define __LV5207LP_H__
> +
> +struct device;
> +
> +struct lv5207lp_platform_data {
> + struct device *fbdev;
> + unsigned int max_value;
> + unsigned int def_value;
> +};
> +
> +#endif
> +
> --
> 1.7.8.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/7] ARM: mach-shmobile: kzm9g: Reference DT implementation
From: Tetsuyuki Kobayashi @ 2012-11-26 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353889014-17142-8-git-send-email-horms@verge.net.au>
Hello Simon-san,
(2012/11/26 9:16), Simon Horman wrote:
> Provide alternate board code for the kzm9g to demonstrate
> how DT may be used given the current state of driver
> device tree support. This is intended to act as a reference
> for mach-shmobile developers.
>
> Some notes:
>
> * Brings up the GIC interrupt handler using device tree
> * Brings up the following devices using device tree
> - ST1232 (Touchscreen)
> - MMCIF (MMC)
> - SDHI (MMC)
> * Does not bring up the INTC interrupt controller at all,
> thus external devices may not be used
> * Uses existing C code and not device tree to initialise the following,
> which are needed for a working board:
> - SCIF (Serial)
> - CMT (Clock)
> - PFC (GPIO)
>
> To use this alternate board code instead of the normal board code,
> CONFIG_MACH_KZM9G_REFERENCE should be selected in the kernel config.
> And the sh73a0-kzm9g-reference.dtb flattened device tree blob should be used.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 153 ++++++++++++++++++++++++
> arch/arm/mach-shmobile/Kconfig | 10 ++
> arch/arm/mach-shmobile/Makefile | 8 +-
> arch/arm/mach-shmobile/board-kzm9g-reference.c | 142 ++++++++++++++++++++++
> 5 files changed, 314 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c1ce813..b6c4fa2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -75,7 +75,8 @@ dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
> dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
> dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
> r8a7740-armadillo800eva.dtb \
> - sh73a0-kzm9g.dtb
> + sh73a0-kzm9g.dtb \
> + sh73a0-kzm9g-reference.dtb
> dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
> spear1340-evb.dtb
> dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
> diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> new file mode 100644
> index 0000000..978892a
> --- /dev/null
> +++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
> @@ -0,0 +1,153 @@
> +/*
> + * Device Tree Source for the KZM-A9-GT board
> + *
> + * Copyright (C) 2012 Horms Solutions Ltd.
> + *
> + * Based on sh73a0-kzm9g.dts
> + * Copyright (C) 2012 Renesas Solutions Corp.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "KZM-A9-GT";
> + compatible = "renesas,kzm9g-reference", "renesas,sh73a0";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x41000000 0x1e800000>;
> + };
> +
> + gic: interrupt-controller@f0001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + interrupt-controller;
> + reg = <0xf0001000 0x1000>,
> + <0xf0000100 0x100>;
> + };
> +
> + i2c0: i2c@0xe6820000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,rmobile-iic";
> + reg = <0xe6820000 0x425>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 167 0x4
> + 0 170 0x4>;
> + };
I reported /dev/i2c-0 seems not working. I found the reason.
About i2c0 interrupt, it should be:
interrupts = <0 167 0x4
0 168 0x4
0 169 0x4
0 170 0x4>;
The same as i2c1 - ic24. There are 4 interrupts each.
> +
> + i2c1: i2c@0xe6822000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,rmobile-iic";
> + reg = <0xe6822000 0x425>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 51 0x4
> + 0 44 0x4>;
interrupts = <0 51 0x4
0 52 0x4
0 53 0x4
0 54 0x4>;
> +
> + touchscreen@55 {
> + compatible = "sitronix,st1232";
> + reg = <0x55>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 9 0x4>;
> + };
> + };
> +
> + i2c2: i2c@0xe6824000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,rmobile-iic";
> + reg = <0xe6824000 0x425>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 171 0x4
0 172 0x4
0 173 0x4
> + 0 174 0x4>;
> + };
> +
> + i2c3: i2c@0xe6826000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,rmobile-iic";
> + reg = <0xe6826000 0x425>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 183 0x4
0 184 0x4
0 185 0x4
> + 0 186 0x4>;
> + };
> +
> + i2c4: i2c@0xe6828000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,rmobile-iic";
> + reg = <0xe6828000 0x425>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 187 0x4
0 188 0x4
0 189 0x4
> + 0 190 0x4>;
> + };
^ permalink raw reply
* Re: [PATCH v5 00/15] shmobile DT initialisation of INTC and GIC
From: Nobuhiro Iwamatsu @ 2012-11-26 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d2z1vza0.wl%kuninori.morimoto.gx@renesas.com>
Thank you for comment.
I already revised your point.
Best regards,
Nobuhiro
On Mon, Nov 26, 2012 at 12:06 PM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
> Hi Iwamatsu-san
>
>> Hi, simon and Magnus.
>>
>> I updated patch series for shmobile DT support.
>> This version fixes definition of interrupt-controller. By this, I fixed
>> external interrupt issuse on sh7372.
>> And update r8a7740 and sh73a0 DT INTC init code to reduce the number of #ifdefs.
>>
>> ---
>>
>> The aims of this series are:
>>
>> * Adding DT support to INTC
>> * Allowing relevant ARM shmobile SoCs to use DT to initialise INTC
>> * Allowing relevant ARM shmobile boards to use DT to initialise INTC
>> * Allowing the sh73a0 SoC use DT to initialise GIC
>> * Allowing the sh73a0 SoC use DT to initialise GIC, which in
>> turn allows the kzm9g board to use DT to initialise GIC
>>
>> Nobuhiro Iwamatsu (12):
>> ARM: mach-shmobile: Add support OF for INTC of shmobile
>> SH: intc: Add support OF of IRQ
>> ARM: mach-shmobile: Add support OF of INTC for r8a7740
>> ARM: mach-shmobile: Add support OF of INTC for sh73a0
>> ARM: mach-shmobile: Add support OF of INTC for sh7372
>> ARM: mach-shmobile: Add DT table of INTC for sh73a0
>> ARM: mach-shmobile: Add DT table of INTC for sh7372
>> ARM: mach-shmobile: Add DT table of INTC for r8a7740
>> ARM: shmobile: Include DTSI of r8a7740 to armadillo800eva
>> ARM: shmobile: Include DTSI of sh73a0 to kzm9g board
>> ARM: shmobile: r8a7740: Use DT initialisation of INTC
>> ARM: shmobile: sh7372: Use DT initialisation of INTC
>>
>> Simon Horman (3):
>> ARM: shmobile: kzm9g: Use DT initialisation of INTC
>> ARM: shmobile: Add DT table of GIC for sh73a0
>> ARM: shmobile: sh73a0: Use DT for GIC
>
> This is not super important, but
> did you check your patch by ./scripts/checkpatch.pl ?
>
> Occasionally it may be unavoidable, but this type of patches can be.
>
>
> Best regards
> ---
> Kuninori Morimoto
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Nobuhiro Iwamatsu
^ permalink raw reply
* Re: [PATCH v2] sh: clkfwk: bugfix: sh_clk_div_enable() care sh_clk_div_set_rate() if div6
From: Paul Mundt @ 2012-11-26 6:23 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87a9u4x5q1.wl%kuninori.morimoto.gx@renesas.com>
On Sun, Nov 25, 2012 at 10:01:46PM -0800, Kuninori Morimoto wrote:
> 764f4e4e33d18cde4dcaf8a0d860b749c6d6d08b
> (sh: clkfwk: Use shared sh_clk_div_enable/disable())
> shared enable/disable funcions for div4/div6.
> But new sh_clk_div_enable() didn't care sh_clk_div_set_rate()
> which is required on div6 clock.
> This patch fixes it.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Looks better, I'll queue it up, thanks.
^ permalink raw reply
* Re: [PATCH 0/7] ARM: mach-shmobile: kzm9g: Reference DT implementation
From: Tetsuyuki Kobayashi @ 2012-11-26 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353889014-17142-1-git-send-email-horms@verge.net.au>
Hello Simon-san,
(2012/11/26 9:16), Simon Horman wrote:
> this series is a first pass at providing a refernce DT implementation
> for the kzm9g baord which is intended to act as a guide for mach-shmobile
> developers.
>
I tried this patch series on v3.7-rc7 with CONFIG_MACH_KZM9G_REFERENCE=y.
It boot up correctly with rootfs on SD card. It works good for following devices
- serial port on /dev/ttySC4
- SD card on /dev/mmcblk0
- micro SD card on /dev/mmcblk1
- eMMC on /dev/mmcblk2
I found /dev/i2c-0 seems not to work correctly. "i2cdump" command fails like this.
# i2cdump 0 0x40
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x40, mode byte
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: [ 180.171875] i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out
[ 180.187500] i2c-sh_mobile i2c-sh_mobile.0: Polling timed out
XX [ 185.187500] i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out
[ 185.203125] i2c-sh_mobile i2c-sh_mobile.0: Polling timed out
XX ^C[ 190.203125] i2c-sh_mobile i2c-sh_mobile.0: Transfer request timed out
[ 190.218750] i2c-sh_mobile i2c-sh_mobile.0: Polling timed out
I quited the command by ^C.
When I try the same on v3.7-rc7 without CONFIG_MACH_KZM9G_REFERENCE=y
"i2cdump" command does not time out and shows some data.
^ permalink raw reply
* [PATCH v2] sh: clkfwk: bugfix: sh_clk_div_enable() care sh_clk_div_set_rate() if div6
From: Kuninori Morimoto @ 2012-11-26 6:01 UTC (permalink / raw)
To: linux-sh
764f4e4e33d18cde4dcaf8a0d860b749c6d6d08b
(sh: clkfwk: Use shared sh_clk_div_enable/disable())
shared enable/disable funcions for div4/div6.
But new sh_clk_div_enable() didn't care sh_clk_div_set_rate()
which is required on div6 clock.
This patch fixes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
>> Paul
This is v2 patch of sh_clk_div_disable() bugfix.
it used SH_CLK_DIV6_MSK as you indicated.
Sorry for my late response.
drivers/sh/clk/cpg.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/sh/clk/cpg.c b/drivers/sh/clk/cpg.c
index 07e9fb4..d118bac 100644
--- a/drivers/sh/clk/cpg.c
+++ b/drivers/sh/clk/cpg.c
@@ -126,6 +126,12 @@ static int sh_clk_div_set_rate(struct clk *clk, unsigned long rate)
static int sh_clk_div_enable(struct clk *clk)
{
+ if (clk->div_mask = SH_CLK_DIV6_MSK) {
+ int ret = sh_clk_div_set_rate(clk, clk->rate);
+ if (ret < 0)
+ return ret;
+ }
+
sh_clk_write(sh_clk_read(clk) & ~CPG_CKSTP_BIT, clk);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 6/7] ARM: mach-shmobile: sh73a0: Minimal setup using DT
From: Simon Horman @ 2012-11-26 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoQmNh5Sz-YLPMvEbp0FhYW=s2tBez+Duex1vyr=yVnPuA@mail.gmail.com>
On Mon, Nov 26, 2012 at 01:23:12PM +0900, Magnus Damm wrote:
> Hi Simon,
>
> Thanks for your efforts.
>
> On Mon, Nov 26, 2012 at 9:16 AM, Simon Horman <horms@verge.net.au> wrote:
> > Allow a minimal setup of the sh73a0 SoC using a flattened device tree.
> >
> > * Allow configuration of the i2c controllers using a flattened device tree.
> >
> > * SCI serial controller and CMT clock source, whose drivers do not yet
> > support configuration using a flattened device tree, are still configured
> > using C code in order to allow booting of a board with this SoC.
> >
> > An example dts snuppet follows:
> >
> > i2c0: i2c@0xe6820000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "renesas,rmobile-iic";
> > reg = <0xe6820000 0x425>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 167 0x4
> > 0 170 0x4>;
> > };
> >
> > i2c1: i2c@0xe6822000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "renesas,rmobile-iic";
> > reg = <0xe6822000 0x425>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 51 0x4
> > 0 44 0x4>;
> >
> > touchscreen@55 {
> > compatible = "sitronix,st1232";
> > reg = <0x55>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 9 0x4>;
> > };
> > };
> >
> > i2c2: i2c@0xe6824000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "renesas,rmobile-iic";
> > reg = <0xe6824000 0x425>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 171 0x4
> > 0 174 0x4>;
> > };
> >
> > i2c3: i2c@0xe6826000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "renesas,rmobile-iic";
> > reg = <0xe6826000 0x425>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 183 0x4
> > 0 186 0x4>;
> > };
> >
> > i2c4: i2c@0xe6828000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "renesas,rmobile-iic";
> > reg = <0xe6828000 0x425>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 187 0x4
> > 0 190 0x4>;
> > };
>
> Uhm, doesn't the above want to go into sh73a0.dtsi?
There are two things that I am unsure of:
* What should go into sh73a0.dtsi and what should go into
sh73a0-kzm9g-refere3nce.dts.
The i2c seems like it should go into sh73a0.dtsi as it is part of the
soc. Likewise the interrupt controllers.
But when it comes to mmcif and sdhi I am less sure.
Both of these make use of regulators. Are the regulators
part of the board or the SoC? If the are part of the board
then it makes it more difficult to put mmcif and sdhi into
sh73a0.dtsi as they need to reference the regulators somehow.
* What to do the of_dev_auxdata.
Currently I add this in patch 4 to the board-kzm9g.c. It is used to force
the name of the i2c, mmcif and sdhi devices in order to allow their clock
lookup to work (though come to think of it it may not be necessary for
mmcif and sdhi).
In any case, the location of the of_dev_auxdata might be come a bit
tricky if it covers devices in both the board and SoC dts files.
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> > ---
> > arch/arm/mach-shmobile/include/mach/common.h | 2 ++
> > arch/arm/mach-shmobile/setup-sh73a0.c | 41 ++++++++++++++++++++++----
> > 2 files changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> > index b50447e..06b905e 100644
> > --- a/arch/arm/mach-shmobile/include/mach/common.h
> > +++ b/arch/arm/mach-shmobile/include/mach/common.h
> > @@ -52,7 +52,9 @@ extern void sh73a0_init_irq(void);
> > extern void sh73a0_init_irq_dt(void);
> > extern void sh73a0_map_io(void);
> > extern void sh73a0_add_early_devices(void);
> > +extern void sh73a0_add_early_devices_dt(void);
> > extern void sh73a0_add_standard_devices(void);
> > +extern void sh73a0_add_standard_devices_dt(void);
> > extern void sh73a0_clock_init(void);
> > extern void sh73a0_pinmux_init(void);
> > extern struct clk sh73a0_extal1_clk;
> > diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
> > index db99a4a..9096caa 100644
> > --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> > +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> > @@ -23,6 +23,7 @@
> > #include <linux/interrupt.h>
> > #include <linux/irq.h>
> > #include <linux/platform_device.h>
> > +#include <linux/of_platform.h>
> > #include <linux/delay.h>
> > #include <linux/input.h>
> > #include <linux/io.h>
> > @@ -754,7 +755,7 @@ static struct platform_device pmu_device = {
> > .resource = pmu_resources,
> > };
> >
> > -static struct platform_device *sh73a0_early_devices[] __initdata = {
> > +static struct platform_device *sh73a0_early_devices_dt[] __initdata = {
> > &scif0_device,
> > &scif1_device,
> > &scif2_device,
> > @@ -765,6 +766,9 @@ static struct platform_device *sh73a0_early_devices[] __initdata = {
> > &scif7_device,
> > &scif8_device,
> > &cmt10_device,
> > +};
> > +
> > +static struct platform_device *sh73a0_early_devices[] __initdata = {
> > &tmu00_device,
> > &tmu01_device,
> > };
> > @@ -782,11 +786,18 @@ static struct platform_device *sh73a0_late_devices[] __initdata = {
> >
> > #define SRCR2 IOMEM(0xe61580b0)
> >
> > -void __init sh73a0_add_standard_devices(void)
> > +void __init sh73a0_add_standard_devices_dt(void)
> > {
> > /* Clear software reset bit on SY-DMAC module */
> > __raw_writel(__raw_readl(SRCR2) & ~(1 << 18), SRCR2);
> >
> > + platform_add_devices(sh73a0_early_devices_dt,
> > + ARRAY_SIZE(sh73a0_early_devices_dt));
> > +}
> > +
> > +void __init sh73a0_add_standard_devices(void)
> > +{
> > + sh73a0_add_standard_devices_dt();
> > platform_add_devices(sh73a0_early_devices,
> > ARRAY_SIZE(sh73a0_early_devices));
> > platform_add_devices(sh73a0_late_devices,
> > @@ -803,14 +814,34 @@ static void __init sh73a0_earlytimer_init(void)
> > sh73a0_register_twd();
> > }
> >
> > -void __init sh73a0_add_early_devices(void)
> > +static void __init
> > +sh73a0_add_early_devices_start(void)
> > {
> > - early_platform_add_devices(sh73a0_early_devices,
> > - ARRAY_SIZE(sh73a0_early_devices));
> > + early_platform_add_devices(sh73a0_early_devices_dt,
> > + ARRAY_SIZE(sh73a0_early_devices_dt));
> > +}
> >
> > +static void __init
> > +sh73a0_add_early_devices_finish(void)
> > +{
> > /* setup early console here as well */
> > shmobile_setup_console();
> >
> > /* override timer setup with soc-specific code */
> > shmobile_timer.init = sh73a0_earlytimer_init;
> > }
> > +
> > +void __init sh73a0_add_early_devices_dt(void)
> > +{
> > + sh73a0_add_early_devices_start();
> > + sh73a0_add_early_devices_finish();
> > +}
>
> What's the reason behind using sh73a0_earlytimer_init() for the sh73a0
> DT case instead of using shmobile_setup_delay() as the DT code for
> sh7372 does?
The reason is that I wasn't aware of shmobile_setup_delay()
> For the DT case on sh7372 we don't really use early platform driver
> timers at all, instead we use timers as regular platform devices. For
> this to work as expected we need to setup a worst case udelay
> calculation via shmobile_setup_delay(). I suggest using the same style
> for sh73a0.
Thanks, I will look into this.
> > +void __init sh73a0_add_early_devices(void)
> > +{
> > + sh73a0_add_early_devices_start();
> > + early_platform_add_devices(sh73a0_early_devices,
> > + ARRAY_SIZE(sh73a0_early_devices));
> > + sh73a0_add_early_devices_finish();
> > +}
> > +
>
> Hm, without sh73a0_earlytimer_init() the functions
> sh73a0_add_early_devices_start() and sh73a0_add_early_devices_finish()
> look overly complicated compared to the sh7372 DT implementation.
I'm not sure that I understand but I will look at refactoring the
code to make use of.
> However, I have not checked your code in detail but if your DT code
> for sh73a0 happens to be shorter than the DT code for sh7372 then
> please adjust the sh7372 code to be as short and simple as possible.
Ok, I'll see what I can do.
^ permalink raw reply
* Re: [PATCH 1/7] mmc: sh-mmcif: provide default allowed voltage
From: Simon Horman @ 2012-11-26 4:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoT8yFx8fe0Fkmh6F91NxajgcPYmheSwpqKk4HtQkX6_pw@mail.gmail.com>
On Mon, Nov 26, 2012 at 01:06:26PM +0900, Magnus Damm wrote:
> Hi Simon,
>
> On Mon, Nov 26, 2012 at 9:16 AM, Simon Horman <horms@verge.net.au> wrote:
> > Use MMC_VDD_165_195 as the allowed voltages in the absence of
> > platform data. This should allow device tree to initialise MMCIF
> > for a number of boards.
> >
> > A more complete solution would be to provide either MMCIF or MMC device
> > try bindings to set the allowed voltages.
> >
> > Tested on the KZM-A9-GT board
> >
> > Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> > ---
> > drivers/mmc/host/sh_mmcif.c | 7 ++-----
> > 1 file changed, 2 insertions(+), 5 deletions(-)
>
> Thanks for your patch!
>
> > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > index 11d2bc3..88d6866 100644
> > --- a/drivers/mmc/host/sh_mmcif.c
> > +++ b/drivers/mmc/host/sh_mmcif.c
> > @@ -1293,12 +1293,9 @@ static void sh_mmcif_init_ocr(struct sh_mmcif_host *host)
> >
> > mmc_regulator_get_supply(mmc);
> >
> > - if (!pd)
> > - return;
> > -
> > if (!mmc->ocr_avail)
> > - mmc->ocr_avail = pd->ocr;
> > - else if (pd->ocr)
> > + mmc->ocr_avail = pd ? pd->ocr : MMC_VDD_165_195;
> > + else if (pd && pd->ocr)
> > dev_warn(mmc_dev(mmc), "Platform OCR mask is ignored\n");
> > }
>
> I may be mistaken, but I somehow thought that the code in
> mmc_regulator_get_supply() would take care of this automatically for
> us already. So this kind of patch isn't really needed as long as you
> tie in regulators via DT as expected.
Thanks, I'll check that. I did write this patch before hooking
up the regulators correctly.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox