[PATCH v1 0/3] ARM64 LPC: legacy ISA I/O support

[PATCH v1 0/3] ARM64 LPC: legacy ISA I/O support

[Rongrong Zou]

The Low Pin Count bus, is used on IBM-compatible personal computers 
to connect low-bandwidth devices to the CPU, such as the boot ROM, 
"legacy" I/O devices (integrated into a super I/O chip), and Trusted
Platform Module (TPM)."Legacy" I/O devices usually include serial and 
parallel ports, PS/2 keyboard, PS/2 mouse, and floppy disk controller.

Usually LPC controller is part of PCI host bridge, so the legacy ISA
port locate on LPC bus can be accessed directly. But some SoC have
independent LPC controller, and we can access the legacy port by specifying
LPC address cycle. Thus, LPC driver is introduced.

In addition, indirect legacy ISA port I/O is introduced, then we can
hook LPC driver to gereral inb/outb inerface. So the driver of device
attached to the LPC bus need no modification.

Generally, X86 server platform is managemented by BMC, The host 
communicate with the BMC across IPMI(BT/KCS). BT(KCS) use the
legacy ISA port which is located on LPC bus. 

The BMC is required on Hisilicon Hip06 arm64 SoC board too.  

  ____     lpc     ____
 |host|___________|BMC |
 |____|           |____|

Rongrong Zou (3):
  ARM64 LPC: indirect ISA PORT IO introduced
  ARM64 LPC: LPC driver implementation
  ARM64 LPC: update binding doc

 .../devicetree/bindings/arm64/low-pin-count.txt    |  20 ++
 arch/arm64/Kconfig.platforms                       |   5 +-
 arch/arm64/include/asm/io.h                        |  78 ++++++
 arch/arm64/kernel/Makefile                         |   1 +
 arch/arm64/kernel/lpc.c                            | 294 +++++++++++++++++++++
 arch/arm64/kernel/setup.c                          |   5 +
 6 files changed, 402 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
 create mode 100644 arch/arm64/kernel/lpc.c

-- 
1.9.1

[PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Rongrong Zou]

Indirect ISA port I/O accessing introduced, vendors can hook
their own in/out function to general inb/outb. Drivers can access
legacy ISA I/O port by inb/outb as it is done in x86 platform.

Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
---
 arch/arm64/Kconfig.platforms |  5 ++-
 arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/setup.c    |  5 +++
 3 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4043c35..98ae206 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -127,5 +127,8 @@ config ARCH_ZYNQMP
 	bool "Xilinx ZynqMP Family"
 	help
 	  This enables support for Xilinx ZynqMP Family
-
+config ARM64_INDIRECT_PIO
+	bool "ARM64 Indirect port I/O"
+	help
+	  This enables support for ARM64 indirect port I/O
 endmenu
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 44be1e0..0041f3b 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
  */
 #define xlate_dev_kmem_ptr(p)	p
 
+#ifdef CONFIG_ARM64_INDIRECT_PIO
+#define DEF_PCI_HOOK_pio(x)   x
+#else
+#define DEF_PCI_HOOK_pio(x)   NULL
+#endif
+
+/*
+ * This value is equal to PCIBIOS_MIN_IO
+ */
+#define LEGACY_ISA_PORT_MAX 0x1000
+
+extern struct arm64_isa_io {
+	u8 (*inb)(unsigned long port);
+	u16 (*inw)(unsigned long port);
+	u32 (*inl)(unsigned long port);
+	void (*outb)(u8 value, unsigned long port);
+	void (*outw)(u16 value, unsigned long port);
+	void (*outl)(u32 value, unsigned long port);
+} arm64_isa_io;
+
+#define inb inb
+static inline u8 inb(unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.inb) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		return arm64_isa_io.inb(port);
+	return readb(PCI_IOBASE + port);
+}
+
+#define inw inw
+static inline u16 inw(unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.inw) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		return arm64_isa_io.inw(port);
+	return readw(PCI_IOBASE + port);
+}
+
+#define inl inl
+static inline u32 inl(unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.inl) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		return arm64_isa_io.inl(port);
+	return readl(PCI_IOBASE + port);
+}
+
+#define outb outb
+static inline void outb(u8 val, unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.outb) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		arm64_isa_io.outb(val, port);
+	else
+		writeb(val, PCI_IOBASE + port);
+}
+
+#define outw outw
+static inline void outw(u16 val, unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.outw) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		arm64_isa_io.outw(val, port);
+	else
+		writew(val, PCI_IOBASE + port);
+}
+
+#define outl outl
+static inline void outl(u32 val, unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.outl) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		arm64_isa_io.outl(val, port);
+	else
+		writel(val, PCI_IOBASE + port);
+}
+
+
 #include <asm-generic/io.h>
 
 /*
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..c689dd7 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -381,3 +381,8 @@ static int __init topology_init(void)
 	return 0;
 }
 subsys_initcall(topology_init);
+
+#if defined(CONFIG_ARM64_INDIRECT_PIO)
+struct arm64_isa_io arm64_isa_io;
+EXPORT_SYMBOL_GPL(arm64_isa_io);
+#endif
-- 
1.9.1

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Arnd Bergmann]

On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
> Indirect ISA port I/O accessing introduced, vendors can hook
> their own in/out function to general inb/outb. Drivers can access
> legacy ISA I/O port by inb/outb as it is done in x86 platform.
> 
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>

Looks correct to me, but I have a few style comments

> ---
>  arch/arm64/Kconfig.platforms |  5 ++-
>  arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/setup.c    |  5 +++
>  3 files changed, 87 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4043c35..98ae206 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>  	bool "Xilinx ZynqMP Family"
>  	help
>  	  This enables support for Xilinx ZynqMP Family
> -
> +config ARM64_INDIRECT_PIO
> +	bool "ARM64 Indirect port I/O"
> +	help
> +	  This enables support for ARM64 indirect port I/O
>  endmenu

The option should probably go into arch/arm64/Kconfig. Possibly you can make
it a silent option that just gets selected whenever a driver is enabled
that might set the callbacks.

> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 44be1e0..0041f3b 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>   */
>  #define xlate_dev_kmem_ptr(p)	p
>  
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> +#define DEF_PCI_HOOK_pio(x)   x
> +#else
> +#define DEF_PCI_HOOK_pio(x)   NULL
> +#endif

Maybe just put the entire definition block inside #ifdef and
fall back to the default inb/outb definitions otherwise.

> +/*
> + * This value is equal to PCIBIOS_MIN_IO
> + */
> +#define LEGACY_ISA_PORT_MAX 0x1000

I would just use PCIBIOS_MIN_IO instead of defining another macro.

> +extern struct arm64_isa_io {
> +	u8 (*inb)(unsigned long port);
> +	u16 (*inw)(unsigned long port);
> +	u32 (*inl)(unsigned long port);
> +	void (*outb)(u8 value, unsigned long port);
> +	void (*outw)(u16 value, unsigned long port);
> +	void (*outl)(u32 value, unsigned long port);
> +} arm64_isa_io;

Maybe make this a single function pointer like

void (*arm64_indirect_pio)(unsigned long port, bool write, int size, void *data);

I'm guessing that this would result in smaller object code at the call sites,
but you'd have to try.

	Arnd

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Rongrong Zou]

Hi Arnd,

Thanks for your comment.

在 2015/12/29 21:47, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
>> Indirect ISA port I/O accessing introduced, vendors can hook
>> their own in/out function to general inb/outb. Drivers can access
>> legacy ISA I/O port by inb/outb as it is done in x86 platform.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>
> Looks correct to me, but I have a few style comments
>
>> ---
>>   arch/arm64/Kconfig.platforms |  5 ++-
>>   arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/setup.c    |  5 +++
>>   3 files changed, 87 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 4043c35..98ae206 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>>   	bool "Xilinx ZynqMP Family"
>>   	help
>>   	  This enables support for Xilinx ZynqMP Family
>> -
>> +config ARM64_INDIRECT_PIO
>> +	bool "ARM64 Indirect port I/O"
>> +	help
>> +	  This enables support for ARM64 indirect port I/O
>>   endmenu
>
> The option should probably go into arch/arm64/Kconfig. Possibly you can make
> it a silent option that just gets selected whenever a driver is enabled
> that might set the callbacks.

I try to bind it with HISILICON platform.

>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 44be1e0..0041f3b 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>>    */
>>   #define xlate_dev_kmem_ptr(p)	p
>>
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> +#define DEF_PCI_HOOK_pio(x)   x
>> +#else
>> +#define DEF_PCI_HOOK_pio(x)   NULL
>> +#endif
>
> Maybe just put the entire definition block inside #ifdef and
> fall back to the default inb/outb definitions otherwise.
>
>> +/*
>> + * This value is equal to PCIBIOS_MIN_IO
>> + */
>> +#define LEGACY_ISA_PORT_MAX 0x1000
>
> I would just use PCIBIOS_MIN_IO instead of defining another macro.

Because PCIBIOS_MIN_IO is defined in asm/pci.h, and asm/io.h
is included by asm/pci.h. so do you mean i define PCIBIOS_MIN_IO here,
and in asm/pci.h just use include asm/io.h ?

>
>> +extern struct arm64_isa_io {
>> +	u8 (*inb)(unsigned long port);
>> +	u16 (*inw)(unsigned long port);
>> +	u32 (*inl)(unsigned long port);
>> +	void (*outb)(u8 value, unsigned long port);
>> +	void (*outw)(u16 value, unsigned long port);
>> +	void (*outl)(u32 value, unsigned long port);
>> +} arm64_isa_io;
>
> Maybe make this a single function pointer like
>
> void (*arm64_indirect_pio)(unsigned long port, bool write, int size, void *data);
>
> I'm guessing that this would result in smaller object code at the call sites,
> but you'd have to try.

OK, i try it.

>
> 	Arnd
>
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Arnd Bergmann]

On Tuesday 29 December 2015 22:26:27 Rongrong Zou wrote:
> 在 2015/12/29 21:47, Arnd Bergmann 写道:
> > On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
> >> Indirect ISA port I/O accessing introduced, vendors can hook
> >> their own in/out function to general inb/outb. Drivers can access
> >> legacy ISA I/O port by inb/outb as it is done in x86 platform.
> >>
> >> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> >
> > Looks correct to me, but I have a few style comments
> >
> >> ---
> >>   arch/arm64/Kconfig.platforms |  5 ++-
> >>   arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
> >>   arch/arm64/kernel/setup.c    |  5 +++
> >>   3 files changed, 87 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >> index 4043c35..98ae206 100644
> >> --- a/arch/arm64/Kconfig.platforms
> >> +++ b/arch/arm64/Kconfig.platforms
> >> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
> >>   	bool "Xilinx ZynqMP Family"
> >>   	help
> >>   	  This enables support for Xilinx ZynqMP Family
> >> -
> >> +config ARM64_INDIRECT_PIO
> >> +	bool "ARM64 Indirect port I/O"
> >> +	help
> >> +	  This enables support for ARM64 indirect port I/O
> >>   endmenu
> >
> > The option should probably go into arch/arm64/Kconfig. Possibly you can make
> > it a silent option that just gets selected whenever a driver is enabled
> > that might set the callbacks.
> 
> I try to bind it with HISILICON platform.

It should be possible to build the actual driver on all platforms, at
least with COMPILE_TEST.

> >> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> >> index 44be1e0..0041f3b 100644
> >> --- a/arch/arm64/include/asm/io.h
> >> +++ b/arch/arm64/include/asm/io.h
> >> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> >>    */
> >>   #define xlate_dev_kmem_ptr(p)	p
> >>
> >> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> >> +#define DEF_PCI_HOOK_pio(x)   x
> >> +#else
> >> +#define DEF_PCI_HOOK_pio(x)   NULL
> >> +#endif
> >
> > Maybe just put the entire definition block inside #ifdef and
> > fall back to the default inb/outb definitions otherwise.
> >
> >> +/*
> >> + * This value is equal to PCIBIOS_MIN_IO
> >> + */
> >> +#define LEGACY_ISA_PORT_MAX 0x1000
> >
> > I would just use PCIBIOS_MIN_IO instead of defining another macro.
> 
> Because PCIBIOS_MIN_IO is defined in asm/pci.h, and asm/io.h
> is included by asm/pci.h. so do you mean i define PCIBIOS_MIN_IO here,
> and in asm/pci.h just use include asm/io.h ?

Yes, I guess that would work.

	Arnd

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Rongrong Zou]

在 2015/12/29 22:35, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 22:26:27 Rongrong Zou wrote:
>> 在 2015/12/29 21:47, Arnd Bergmann 写道:
>>> On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
>>>> Indirect ISA port I/O accessing introduced, vendors can hook
>>>> their own in/out function to general inb/outb. Drivers can access
>>>> legacy ISA I/O port by inb/outb as it is done in x86 platform.
>>>>
>>>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>>>
>>> Looks correct to me, but I have a few style comments
>>>
>>>> ---
>>>>    arch/arm64/Kconfig.platforms |  5 ++-
>>>>    arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
>>>>    arch/arm64/kernel/setup.c    |  5 +++
>>>>    3 files changed, 87 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>> index 4043c35..98ae206 100644
>>>> --- a/arch/arm64/Kconfig.platforms
>>>> +++ b/arch/arm64/Kconfig.platforms
>>>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>>>>    	bool "Xilinx ZynqMP Family"
>>>>    	help
>>>>    	  This enables support for Xilinx ZynqMP Family
>>>> -
>>>> +config ARM64_INDIRECT_PIO
>>>> +	bool "ARM64 Indirect port I/O"
>>>> +	help
>>>> +	  This enables support for ARM64 indirect port I/O
>>>>    endmenu
>>>
>>> The option should probably go into arch/arm64/Kconfig. Possibly you can make
>>> it a silent option that just gets selected whenever a driver is enabled
>>> that might set the callbacks.
>>
>> I try to bind it with HISILICON platform.
>
> It should be possible to build the actual driver on all platforms, at
> least with COMPILE_TEST.

Sorry, I'm a little confused, can you describe it in detail?

>
>>>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>>>> index 44be1e0..0041f3b 100644
>>>> --- a/arch/arm64/include/asm/io.h
>>>> +++ b/arch/arm64/include/asm/io.h
>>>> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>>>>     */
>>>>    #define xlate_dev_kmem_ptr(p)	p
>>>>
>>>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>>>> +#define DEF_PCI_HOOK_pio(x)   x
>>>> +#else
>>>> +#define DEF_PCI_HOOK_pio(x)   NULL
>>>> +#endif
>>>
>>> Maybe just put the entire definition block inside #ifdef and
>>> fall back to the default inb/outb definitions otherwise.
>>>
>>>> +/*
>>>> + * This value is equal to PCIBIOS_MIN_IO
>>>> + */
>>>> +#define LEGACY_ISA_PORT_MAX 0x1000
>>>
>>> I would just use PCIBIOS_MIN_IO instead of defining another macro.
>>
>> Because PCIBIOS_MIN_IO is defined in asm/pci.h, and asm/io.h
>> is included by asm/pci.h. so do you mean i define PCIBIOS_MIN_IO here,
>> and in asm/pci.h just use include asm/io.h ?
>
> Yes, I guess that would work.
>
> 	Arnd
>
> .
>

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Arnd Bergmann]

On Wednesday 30 December 2015 09:24:04 Rongrong Zou wrote:
> >>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>>> index 4043c35..98ae206 100644
> >>>> --- a/arch/arm64/Kconfig.platforms
> >>>> +++ b/arch/arm64/Kconfig.platforms
> >>>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
> >>>>            bool "Xilinx ZynqMP Family"
> >>>>            help
> >>>>              This enables support for Xilinx ZynqMP Family
> >>>> -
> >>>> +config ARM64_INDIRECT_PIO
> >>>> +  bool "ARM64 Indirect port I/O"
> >>>> +  help
> >>>> +    This enables support for ARM64 indirect port I/O
> >>>>    endmenu
> >>>
> >>> The option should probably go into arch/arm64/Kconfig. Possibly you can make
> >>> it a silent option that just gets selected whenever a driver is enabled
> >>> that might set the callbacks.
> >>
> >> I try to bind it with HISILICON platform.
> >
> > It should be possible to build the actual driver on all platforms, at
> > least with COMPILE_TEST.
> 
> Sorry, I'm a little confused, can you describe it in detail?
> 
> 

config ARM64_INDIRECT_PIO
	bool
	help
	  Any driver that provides indirect ISA I/O port access should select
	  this symbol

config HISILICON_HI123456_LPC
	bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
	depends on ARCH_HISI || COMPILE_TEST
	select ARM64_INDIRECT_PIO
	help
	  ...


	Arnd

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Rongrong Zou]

在 2015/12/30 16:59, Arnd Bergmann 写道:
> On Wednesday 30 December 2015 09:24:04 Rongrong Zou wrote:
>>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>>> index 4043c35..98ae206 100644
>>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>>>>>>             bool "Xilinx ZynqMP Family"
>>>>>>             help
>>>>>>               This enables support for Xilinx ZynqMP Family
>>>>>> -
>>>>>> +config ARM64_INDIRECT_PIO
>>>>>> +  bool "ARM64 Indirect port I/O"
>>>>>> +  help
>>>>>> +    This enables support for ARM64 indirect port I/O
>>>>>>     endmenu
>>>>>
>>>>> The option should probably go into arch/arm64/Kconfig. Possibly you can make
>>>>> it a silent option that just gets selected whenever a driver is enabled
>>>>> that might set the callbacks.
>>>>
>>>> I try to bind it with HISILICON platform.
>>>
>>> It should be possible to build the actual driver on all platforms, at
>>> least with COMPILE_TEST.
>>
>> Sorry, I'm a little confused, can you describe it in detail?
>>
>>
>
> config ARM64_INDIRECT_PIO
> 	bool
> 	help
> 	  Any driver that provides indirect ISA I/O port access should select
> 	  this symbol


>
> config HISILICON_HI123456_LPC
> 	bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
> 	depends on ARCH_HISI || COMPILE_TEST
> 	select ARM64_INDIRECT_PIO
> 	help
> 	  ...
Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?



>
>
> 	Arnd
>
> .
>

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Arnd Bergmann]

On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote:
> >>
> >
> > config ARM64_INDIRECT_PIO
> >       bool
> >       help
> >         Any driver that provides indirect ISA I/O port access should select
> >         this symbol
> 
> 
> >
> > config HISILICON_HI123456_LPC
> >       bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
> >       depends on ARCH_HISI || COMPILE_TEST
> >       select ARM64_INDIRECT_PIO
> >       help
> >         ...
> Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?

The first should be in the main Kconfig file for arm64, the second one depends
on where we put the respective code. I'd say both the Kconfig entry and the file
can go into drivers/bus, but arch/arm64/kernel/ is also fine with me.

	Arnd

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Will Deacon]

On Wed, Dec 30, 2015 at 10:42:50AM +0100, Arnd Bergmann wrote:
> On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote:
> > >>
> > >
> > > config ARM64_INDIRECT_PIO
> > >       bool
> > >       help
> > >         Any driver that provides indirect ISA I/O port access should select
> > >         this symbol
> > 
> > 
> > >
> > > config HISILICON_HI123456_LPC
> > >       bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
> > >       depends on ARCH_HISI || COMPILE_TEST
> > >       select ARM64_INDIRECT_PIO
> > >       help
> > >         ...
> > Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?
> 
> The first should be in the main Kconfig file for arm64, the second one depends
> on where we put the respective code. I'd say both the Kconfig entry and the file
> can go into drivers/bus, but arch/arm64/kernel/ is also fine with me.

Unsurprisingly, I'd *much* prefer drivers/bus/ !

Will

Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Rongrong Zou]

在 2016/1/4 18:11, Will Deacon 写道:
> On Wed, Dec 30, 2015 at 10:42:50AM +0100, Arnd Bergmann wrote:
>> On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote:
>>>>>
>>>>
>>>> config ARM64_INDIRECT_PIO
>>>>        bool
>>>>        help
>>>>          Any driver that provides indirect ISA I/O port access should select
>>>>          this symbol
>>>
>>>
>>>>
>>>> config HISILICON_HI123456_LPC
>>>>        bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
>>>>        depends on ARCH_HISI || COMPILE_TEST
>>>>        select ARM64_INDIRECT_PIO
>>>>        help
>>>>          ...
>>> Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?
>>
>> The first should be in the main Kconfig file for arm64, the second one depends
>> on where we put the respective code. I'd say both the Kconfig entry and the file
>> can go into drivers/bus, but arch/arm64/kernel/ is also fine with me.
>
> Unsurprisingly, I'd *much* prefer drivers/bus/ !

I'll move it to drivers/bus on next version of patch, thanks!

>
> Will
>
> .
>

[PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

[Rongrong Zou]

? 2016/1/4 18:11, Will Deacon ??:
> On Wed, Dec 30, 2015 at 10:42:50AM +0100, Arnd Bergmann wrote:
>> On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote:
>>>>>
>>>>
>>>> config ARM64_INDIRECT_PIO
>>>>        bool
>>>>        help
>>>>          Any driver that provides indirect ISA I/O port access should select
>>>>          this symbol
>>>
>>>
>>>>
>>>> config HISILICON_HI123456_LPC
>>>>        bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
>>>>        depends on ARCH_HISI || COMPILE_TEST
>>>>        select ARM64_INDIRECT_PIO
>>>>        help
>>>>          ...
>>> Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?
>>
>> The first should be in the main Kconfig file for arm64, the second one depends
>> on where we put the respective code. I'd say both the Kconfig entry and the file
>> can go into drivers/bus, but arch/arm64/kernel/ is also fine with me.
>
> Unsurprisingly, I'd *much* prefer drivers/bus/ !

I'll move it to drivers/bus on next version of patch, thanks!

>
> Will
>
> .
>

[PATCH v1 2/3] ARM64 LPC: LPC driver implementation

[Rongrong Zou]

We only implement io cycles here, we hook the lpc_io_write_byte
and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
the legacy ISA I/O port need no modification.

The low pin count specification is at 
http://www.intel.com/design/chipsets/industry/lpc.htm

Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
---
 arch/arm64/kernel/Makefile |   1 +
 arch/arm64/kernel/lpc.c    | 294 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 295 insertions(+)
 create mode 100644 arch/arm64/kernel/lpc.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 474691f..4324575 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -41,6 +41,7 @@ arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
 arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
+arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO)	+= lpc.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/lpc.c b/arch/arm64/kernel/lpc.c
new file mode 100644
index 0000000..174c293
--- /dev/null
+++ b/arch/arm64/kernel/lpc.c
@@ -0,0 +1,294 @@
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/version.h>
+
+#define LPC_REG_START            (0x00)
+#define LPC_REG_OP_STATUS        (0x04)
+#define LPC_REG_IRQ_ST           (0x08)
+#define LPC_REG_OP_LEN           (0x10)
+#define LPC_REG_CMD              (0x14)
+#define LPC_REG_FWH_ID_MSIZE     (0x18)
+#define LPC_REG_ADDR             (0x20)
+#define LPC_REG_WDATA            (0x24)
+#define LPC_REG_RDATA            (0x28)
+#define LPC_REG_LONG_CNT         (0x30)
+#define LPC_REG_TX_FIFO_ST       (0x50)
+#define LPC_REG_RX_FIFO_ST       (0x54)
+#define LPC_REG_TIME_OUT         (0x58)
+#define LPC_REG_STRQ_CTRL0       (0x80)
+#define LPC_REG_STRQ_CTRL1       (0x84)
+#define LPC_REG_STRQ_INT         (0x90)
+#define LPC_REG_STRQ_INT_MASK    (0x94)
+#define LPC_REG_STRQ_STAT        (0xa0)
+
+#define LPC_CMD_SAMEADDR_SING    (0x00000008)
+#define LPC_CMD_SAMEADDR_INC     (0x00000000)
+#define LPC_CMD_TYPE_IO          (0x00000000)
+#define LPC_CMD_TYPE_MEM         (0x00000002)
+#define LPC_CMD_TYPE_FWH         (0x00000004)
+#define LPC_CMD_WRITE            (0x00000001)
+#define LPC_CMD_READ             (0x00000000)
+
+#define LPC_IRQ_CLEAR            (0x02)
+#define LPC_IRQ_OCCURRED         (0x02)
+#define LPC_STATUS_DILE          (0x01)
+#define LPC_OP_FINISHED          (0x02)
+#define START_WORK (0x01)
+
+#define LPC_FRAME_LEN (0x10)
+
+#define LPC_CURR_STATUS_IDLE     0
+#define LPC_CURR_STATUS_START    1
+#define LPC_CURR_STATUS_TYPE_DIR 2
+#define LPC_CURR_STATUS_ADDR     3
+#define LPC_CURR_STATUS_MSIZE    4
+#define LPC_CURR_STATUS_WDATA    5
+#define LPC_CURR_STATUS_TARHOST  6
+#define LPC_CURR_STATUS_SYNC     7
+#define LPC_CURR_STATUS_RDATA    8
+#define LPC_CURR_STATUS_TARSLAVE 9
+#define LPC_CURR_STATUS_ABORT    10
+
+struct lpc_dev {
+	spinlock_t lock;
+	void __iomem  *regs;
+	struct device *dev;
+};
+
+static struct lpc_dev *lpc_dev;
+
+int lpc_master_write(unsigned int slv_access_mode, unsigned int cycle_type,
+		      unsigned int addr, unsigned char *buf, unsigned int len)
+{
+	unsigned int i;
+	unsigned int lpc_cmd_value;
+	unsigned int lpc_op_state_value;
+	unsigned int retry = 0;
+
+	/* para check */
+	if (!buf || !len)
+		return -EINVAL;
+
+	if (slv_access_mode != LPC_CMD_SAMEADDR_SING &&
+		slv_access_mode != LPC_CMD_SAMEADDR_INC) {
+		return -EINVAL;
+	}
+
+	if ((cycle_type != LPC_CMD_TYPE_IO) &&
+		(cycle_type != LPC_CMD_TYPE_MEM) &&
+		(cycle_type != LPC_CMD_TYPE_FWH)) {
+		return -EINVAL;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+	retry = 0;
+	while (!(readl(lpc_dev->regs + LPC_REG_OP_STATUS)
+		& LPC_STATUS_DILE)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	/* set lpc master write cycle type and slv access mode */
+	lpc_cmd_value = LPC_CMD_WRITE | cycle_type | slv_access_mode;
+	writel(lpc_cmd_value, lpc_dev->regs + LPC_REG_CMD);
+
+	/* set lpc op len */
+	writel(len, lpc_dev->regs + LPC_REG_OP_LEN);
+
+	/* Set write data */
+	for (i = 0; i < len; i++)
+		writel(buf[i], lpc_dev->regs + LPC_REG_WDATA);
+
+	/* set lpc addr config */
+	writel(addr, lpc_dev->regs + LPC_REG_ADDR);
+
+	/* set lpc start work */
+	writel(START_WORK, lpc_dev->regs + LPC_REG_START);
+
+	retry = 0;
+	while (!(readl(lpc_dev->regs + LPC_REG_IRQ_ST) &
+		 LPC_IRQ_OCCURRED)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+
+	lpc_op_state_value = readl(lpc_dev->regs + LPC_REG_OP_STATUS);
+	if (lpc_op_state_value & LPC_OP_FINISHED)
+		return 0;
+
+	return -EIO;
+}
+
+void  lpc_io_write_byte(u8 value, unsigned long addr)
+{
+	unsigned long flags;
+
+	if (!lpc_dev)
+		return;
+	spin_lock_irqsave(&lpc_dev->lock, flags);
+	(void)lpc_master_write(LPC_CMD_SAMEADDR_SING, LPC_CMD_TYPE_IO,
+				 addr, &value, 1);
+	spin_unlock_irqrestore(&lpc_dev->lock, flags);
+}
+
+int lpc_master_read(unsigned int slv_access_mode, unsigned int cycle_type,
+		     unsigned int addr, unsigned char *buf, unsigned int len)
+{
+	unsigned int i;
+	unsigned int lpc_cmd_value;
+	unsigned int lpc_op_state_value;
+	unsigned int retry = 0;
+
+	/* para check */
+	if (!buf || !len)
+		return -EINVAL;
+
+	if (slv_access_mode != LPC_CMD_SAMEADDR_SING &&
+	    slv_access_mode != LPC_CMD_SAMEADDR_INC) {
+		return -EINVAL;
+	}
+
+	if (cycle_type != LPC_CMD_TYPE_IO &&
+	    cycle_type != LPC_CMD_TYPE_MEM &&
+	    cycle_type != LPC_CMD_TYPE_FWH) {
+		return -EINVAL;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+
+	retry = 0;
+	while (!(readl(lpc_dev->regs + LPC_REG_OP_STATUS) &
+	       LPC_STATUS_DILE)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	/* set lpc master read cycle type and slv access mode */
+	lpc_cmd_value = LPC_CMD_READ | cycle_type | slv_access_mode;
+	writel(lpc_cmd_value, lpc_dev->regs + LPC_REG_CMD);
+
+	/* set lpc op len */
+	writel(len, lpc_dev->regs + LPC_REG_OP_LEN);
+
+	/* set lpc addr config */
+	writel(addr, lpc_dev->regs + LPC_REG_ADDR);
+
+	/* set lpc start work */
+	writel(START_WORK, lpc_dev->regs + LPC_REG_START);
+
+	while (!(readl(lpc_dev->regs + LPC_REG_IRQ_ST) &
+	       LPC_IRQ_OCCURRED)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+
+	lpc_op_state_value = readl(lpc_dev->regs + LPC_REG_OP_STATUS);
+	/* Get read data */
+	if (lpc_op_state_value & LPC_OP_FINISHED) {
+		for (i = 0; i < len; i++)
+			buf[i] = readl(lpc_dev->regs + LPC_REG_RDATA);
+		return 0;
+	}
+	return -EIO;
+}
+
+u8 lpc_io_read_byte(unsigned long addr)
+{
+	unsigned char value;
+	unsigned long flags;
+	int ret;
+
+	if (!lpc_dev)
+		return 0xff;
+
+	spin_lock_irqsave(&lpc_dev->lock, flags);
+	ret = lpc_master_read(LPC_CMD_SAMEADDR_SING,
+		LPC_CMD_TYPE_IO, addr, &value, 1);
+	spin_unlock_irqrestore(&lpc_dev->lock, flags);
+	return ret ? 0xff : value;
+}
+
+static const struct arm64_isa_io lpc_io = {
+	.inb  = lpc_io_read_byte,
+	.outb = lpc_io_write_byte,
+};
+
+static int lpc_probe(struct platform_device *pdev)
+{
+	struct resource *regs = NULL;
+
+	lpc_dev = devm_kzalloc(&pdev->dev,
+		sizeof(struct lpc_dev), GFP_KERNEL);
+	if (!lpc_dev)
+		return -ENOMEM;
+
+	spin_lock_init(&lpc_dev->lock);
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	lpc_dev->regs = devm_ioremap_resource(&pdev->dev, regs);
+	if (IS_ERR(lpc_dev->regs))
+		return PTR_ERR(lpc_dev->regs);
+
+	dev_info(&pdev->dev, "Low pin count driver initialized successfully\n");
+
+	lpc_dev->dev = &pdev->dev;
+	platform_set_drvdata(pdev, lpc_dev);
+	arm64_isa_io = lpc_io;
+
+	return 0;
+}
+
+static int lpc_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static const struct of_device_id lpc_pltfm_match[] = {
+	{
+		.compatible = "low-pin-count",
+	},
+	{},
+};
+
+static struct platform_driver lpc_driver = {
+	.driver = {
+		.name           = "LPC",
+		.owner          = THIS_MODULE,
+		.of_match_table = lpc_pltfm_match,
+	},
+	.probe                = lpc_probe,
+	.remove               = lpc_remove,
+};
+
+static int __init lpc_init_driver(void)
+{
+	return platform_driver_register(&lpc_driver);
+}
+
+static void __exit lpc_init_exit(void)
+{
+	platform_driver_unregister(&lpc_driver);
+}
+
+arch_initcall(lpc_init_driver);
+module_exit(lpc_init_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Huawei Tech. Co., Ltd.");
+MODULE_DESCRIPTION("LPC driver for linux");
+MODULE_VERSION("v1.0");
-- 
1.9.1

Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

[Arnd Bergmann]

On Tuesday 29 December 2015 21:33:51 Rongrong Zou wrote:
> We only implement io cycles here, we hook the lpc_io_write_byte
> and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
> the legacy ISA I/O port need no modification.
> 
> The low pin count specification is at 
> http://www.intel.com/design/chipsets/industry/lpc.htm
> 
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>

I'm slightly confused here: I thought this driver was hisilicon specific.
Is the MMIO register layout that is used in this hardware actually standardized
in a way that the driver also works for all other implementations?

> +
> +static struct lpc_dev *lpc_dev;
> +
> +int lpc_master_write(unsigned int slv_access_mode, unsigned int cycle_type,
> +		      unsigned int addr, unsigned char *buf, unsigned int len)
> +{

Please make all function definitions 'static' so we don't accidentally get
other users that bypass the proper interface.

	Arnd

Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

[Rongrong Zou]

在 2015/12/29 21:51, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:51 Rongrong Zou wrote:
>> We only implement io cycles here, we hook the lpc_io_write_byte
>> and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
>> the legacy ISA I/O port need no modification.
>>
>> The low pin count specification is at
>> http://www.intel.com/design/chipsets/industry/lpc.htm
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>
> I'm slightly confused here: I thought this driver was hisilicon specific.
> Is the MMIO register layout that is used in this hardware actually standardized
> in a way that the driver also works for all other implementations?

The register defined is not standardized. other vendors may define their own
registers.

>
>> +
>> +static struct lpc_dev *lpc_dev;
>> +
>> +int lpc_master_write(unsigned int slv_access_mode, unsigned int cycle_type,
>> +		      unsigned int addr, unsigned char *buf, unsigned int len)
>> +{
>
> Please make all function definitions 'static' so we don't accidentally get
> other users that bypass the proper interface.
>
> 	Arnd
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
>

Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

[Arnd Bergmann]

On Tuesday 29 December 2015 22:03:14 Rongrong Zou wrote:
> 在 2015/12/29 21:51, Arnd Bergmann 写道:
> > On Tuesday 29 December 2015 21:33:51 Rongrong Zou wrote:
> >> We only implement io cycles here, we hook the lpc_io_write_byte
> >> and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
> >> the legacy ISA I/O port need no modification.
> >>
> >> The low pin count specification is at
> >> http://www.intel.com/design/chipsets/industry/lpc.htm
> >>
> >> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> >
> > I'm slightly confused here: I thought this driver was hisilicon specific.
> > Is the MMIO register layout that is used in this hardware actually standardized
> > in a way that the driver also works for all other implementations?
> 
> The register defined is not standardized. other vendors may define their own
> registers.

Ok, please clarify this in the patch description, the Kconfig help text and
the DT binding then.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
---
 .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt

diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
new file mode 100644
index 0000000..215f2c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
@@ -0,0 +1,20 @@
+Low Pin Count bus driver
+
+Usually LPC controller is part of PCI host bridge, so the legacy ISA
+port locate on LPC bus can be accessed directly. But some SoC have
+independent LPC controller, and we can access the legacy port by specifying
+LPC address cycle. Thus, LPC driver is introduced.
+
+Required properties:
+- compatible: "low-pin-count"
+- reg: specifies low pin count address range
+
+
+Example:
+
+        lpc_0: lpc@a01b0000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+                compatible = "low-pin-count";
+                reg = <0x0 0xa01b0000 0x0 0x10000>;
+        };
-- 
1.9.1

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
>  .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt

Please add a patch description above and Cc the devicetree mailing list
when you submit it again.

> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> new file mode 100644
> index 0000000..215f2c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> @@ -0,0 +1,20 @@
> +Low Pin Count bus driver
> +
> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
> +port locate on LPC bus can be accessed directly. But some SoC have
> +independent LPC controller, and we can access the legacy port by specifying
> +LPC address cycle. Thus, LPC driver is introduced.
> +
> +Required properties:
> +- compatible: "low-pin-count"
> +- reg: specifies low pin count address range
> +

It would be good to add an explanation about the address space for child
devices.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
>  .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> new file mode 100644
> index 0000000..215f2c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> @@ -0,0 +1,20 @@
> +Low Pin Count bus driver
> +
> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
> +port locate on LPC bus can be accessed directly. But some SoC have
> +independent LPC controller, and we can access the legacy port by specifying
> +LPC address cycle. Thus, LPC driver is introduced.
> +
> +Required properties:
> +- compatible: "low-pin-count"
> +- reg: specifies low pin count address range
> +
> +
> +Example:
> +
> +        lpc_0: lpc@a01b0000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +                compatible = "low-pin-count";
> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
> +        };

One more thought: please try to stick as closely as possible to the existing
ISA binding that is documented at

http://www.firmware.org/1275/bindings/isa/isa0_4d.ps

In particular, this should cover the possibility of describing both memory
and I/O spaces in child devices.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

Sorry for so late reply, it is difficult for me to understand ISA config :( .

在 2015/12/30 17:06, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>>   .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> new file mode 100644
>> index 0000000..215f2c4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> @@ -0,0 +1,20 @@
>> +Low Pin Count bus driver
>> +
>> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
>> +port locate on LPC bus can be accessed directly. But some SoC have
>> +independent LPC controller, and we can access the legacy port by specifying
>> +LPC address cycle. Thus, LPC driver is introduced.
>> +
>> +Required properties:
>> +- compatible: "low-pin-count"
>> +- reg: specifies low pin count address range
>> +
>> +
>> +Example:
>> +
>> +        lpc_0: lpc@a01b0000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +                compatible = "low-pin-count";
>> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>> +        };
>
> One more thought: please try to stick as closely as possible to the existing
> ISA binding that is documented at
>
> http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
 From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
>
> In particular, this should cover the possibility of describing both memory
> and I/O spaces in child devices.
>

I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"

isa@1e {
                                 device_type = "isa";
                                 #interrupt-cells = <2>;
                                 #size-cells = <1>;
                                 #address-cells = <2>;
                                 reg = <0xf000 0x0 0x0 0x0 0x0>;
                                 ranges = <0x1 0x0 0x1000000 0x0 0x0
                                           0x1000>;
                                 interrupt-parent = <&i8259>;



                                 rtc@70 {
                                         compatible = "pnpPNP,b00";
                                         reg = <0x1 0x70 0x2>;
                                 };
  the isa space in child-node: reg = <0x1 0x70 0x2>;
  0x1 means IO space, 70 means addr, 0x2 is size.
  but when i config the following in dts, the ipmi_0 node can't be probed,
  I think there may be some problems.

lpc_0: lpc@a01b0000 {
	compatible = "low-pin-count";
	device_type = "isa";
	#address-cells = <2>;
	#size-cells = <1>;
	reg = <0x0 0xa01b0000 0x0 0x10000>;

	ipmi_0:ipmi@000000e4{
		device_type = "ipmi";
		compatible = "ipmi-bt";
		reg = <0x1 0x000000e4 0x4>;
};







> 	Arnd
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
>

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

Sorry for so late reply, it is difficult for me to understand ISA config :( .

在 2015/12/30 17:06, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>> Signed-off-by: Rongrong Zou <zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>   .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> new file mode 100644
>> index 0000000..215f2c4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> @@ -0,0 +1,20 @@
>> +Low Pin Count bus driver
>> +
>> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
>> +port locate on LPC bus can be accessed directly. But some SoC have
>> +independent LPC controller, and we can access the legacy port by specifying
>> +LPC address cycle. Thus, LPC driver is introduced.
>> +
>> +Required properties:
>> +- compatible: "low-pin-count"
>> +- reg: specifies low pin count address range
>> +
>> +
>> +Example:
>> +
>> +        lpc_0: lpc@a01b0000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +                compatible = "low-pin-count";
>> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>> +        };
>
> One more thought: please try to stick as closely as possible to the existing
> ISA binding that is documented at
>
> http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
 From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
>
> In particular, this should cover the possibility of describing both memory
> and I/O spaces in child devices.
>

I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"

isa@1e {
                                 device_type = "isa";
                                 #interrupt-cells = <2>;
                                 #size-cells = <1>;
                                 #address-cells = <2>;
                                 reg = <0xf000 0x0 0x0 0x0 0x0>;
                                 ranges = <0x1 0x0 0x1000000 0x0 0x0
                                           0x1000>;
                                 interrupt-parent = <&i8259>;



                                 rtc@70 {
                                         compatible = "pnpPNP,b00";
                                         reg = <0x1 0x70 0x2>;
                                 };
  the isa space in child-node: reg = <0x1 0x70 0x2>;
  0x1 means IO space, 70 means addr, 0x2 is size.
  but when i config the following in dts, the ipmi_0 node can't be probed,
  I think there may be some problems.

lpc_0: lpc@a01b0000 {
	compatible = "low-pin-count";
	device_type = "isa";
	#address-cells = <2>;
	#size-cells = <1>;
	reg = <0x0 0xa01b0000 0x0 0x10000>;

	ipmi_0:ipmi@000000e4{
		device_type = "ipmi";
		compatible = "ipmi-bt";
		reg = <0x1 0x000000e4 0x4>;
};







> 	Arnd
> _______________________________________________
> linuxarm mailing list
> linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> 在 2015/12/30 17:06, Arnd Bergmann 写道:
> > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >> +Example:
> >> +
> >> +        lpc_0: lpc@a01b0000 {
> >> +		#address-cells = <1>;
> >> +		#size-cells = <1>;
> >> +                compatible = "low-pin-count";
> >> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
> >> +        };
> >
> > One more thought: please try to stick as closely as possible to the existing
> > ISA binding that is documented at
> >
> > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>  From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
> >
> > In particular, this should cover the possibility of describing both memory
> > and I/O spaces in child devices.
> >
> 
> I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"
> 
> isa@1e {
>                                  device_type = "isa";
>                                  #interrupt-cells = <2>;
>                                  #size-cells = <1>;
>                                  #address-cells = <2>;
>                                  reg = <0xf000 0x0 0x0 0x0 0x0>;
>                                  ranges = <0x1 0x0 0x1000000 0x0 0x0
>                                            0x1000>;
>                                  interrupt-parent = <&i8259>;
> 
> 
> 
>                                  rtc@70 {
>                                          compatible = "pnpPNP,b00";
>                                          reg = <0x1 0x70 0x2>;
>                                  };
>   the isa space in child-node: reg = <0x1 0x70 0x2>;
>   0x1 means IO space, 70 means addr, 0x2 is size.
>   but when i config the following in dts, the ipmi_0 node can't be probed,
>   I think there may be some problems.
> 
> lpc_0: lpc@a01b0000 {
> 	compatible = "low-pin-count";
> 	device_type = "isa";
> 	#address-cells = <2>;
> 	#size-cells = <1>;
> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> 
> 	ipmi_0:ipmi@000000e4{
> 		device_type = "ipmi";
> 		compatible = "ipmi-bt";
> 		reg = <0x1 0x000000e4 0x4>;
> };

The DT sample above looks good in principle. I believe what you are missing
here is code in your driver to scan the child nodes to create the platform
devices. of_bus_isa_translate() should work with your definition here
and create the correct IORESOURCE_IO resources. You don't have any MMIO
resources, so the absence of a ranges property is ok. Maybe all you 
are missing is a call to of_platform_populate() or of_platform_bus_probe()?

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2015/12/31 23:00, Rongrong Zou 写道:
>
>
> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>  >
>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>  > > >> +Example:
>  > > >> +
>  > > >> +        lpc_0: lpc@a01b0000 {
>  > > >> +          #address-cells = <1>;
>  > > >> +          #size-cells = <1>;
>  > > >> +                compatible = "low-pin-count";
>  > > >> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>  > > >> +        };
>  > > >
>  > > > One more thought: please try to stick as closely as possible to the existing
>  > > > ISA binding that is documented at
>  > > >
>  > > > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>  > >  From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
>  > > >
>  > > > In particular, this should cover the possibility of describing both memory
>  > > > and I/O spaces in child devices.
>  > > >
>  > >
>  > > I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"
>  > >
>  > > isa@1e {
>  > >                                  device_type = "isa";
>  > >                                  #interrupt-cells = <2>;
>  > >                                  #size-cells = <1>;
>  > >                                  #address-cells = <2>;
>  > >                                  reg = <0xf000 0x0 0x0 0x0 0x0>;
>  > >                                  ranges = <0x1 0x0 0x1000000 0x0 0x0
>  > >                                            0x1000>;
>  > >                                  interrupt-parent = <&i8259>;
>  > >
>  > >
>  > >
>  > >                                  rtc@70 {
>  > >                                          compatible = "pnpPNP,b00";
>  > >                                          reg = <0x1 0x70 0x2>;
>  > >                                  };
>  > >   the isa space in child-node: reg = <0x1 0x70 0x2>;
>  > >   0x1 means IO space, 70 means addr, 0x2 is size.
>  > >   but when i config the following in dts, the ipmi_0 node can't be probed,
>  > >   I think there may be some problems.
>  > >
>  > > lpc_0: lpc@a01b0000 {
>  > >       compatible = "low-pin-count";
>  > >       device_type = "isa";
>  > >       #address-cells = <2>;
>  > >       #size-cells = <1>;
>  > >       reg = <0x0 0xa01b0000 0x0 0x10000>;
>  > >
>  > >       ipmi_0:ipmi@000000e4{
>  > >               device_type = "ipmi";
>  > >               compatible = "ipmi-bt";
>  > >               reg = <0x1 0x000000e4 0x4>;
>  > > };
>  >
>  > The DT sample above looks good in principle. I believe what you are missing
>  > here is code in your driver to scan the child nodes to create the platform
>  > devices. of_bus_isa_translate() should work with your definition here
>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>  > resources, so the absence of a ranges property is ok. Maybe all you
>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>  >
>
> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> will be sent later. By the way, it's my another email account use when i at home.

I tried, and there need some additional changes.

isa@a01b0000 {

/*the node name should start with "isa", because of below definition
* static int of_bus_isa_match(struct device_node *np)
* {
*	return !strcmp(np->name, "isa");
* }
*/
	compatible = "low-pin-count";
	device_type = "isa";
	#address-cells = <2>;
	#size-cells = <1>;
	reg = <0x0 0xa01b0000 0x0 0x10000>;
	ranges = <0x1 0x0 0x0 0x0 0x1000>;
/*
*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
*
*/
	ipmi_0:ipmi@000000e4{
		device_type = "ipmi";
		compatible = "ipmi-bt";
		reg = <0x1 0x000000e4 0x4>;
};

drivers\of\address.c
static int __of_address_to_resource(struct device_node *dev,
                 const __be32 *addrp, u64 size, unsigned int flags,
                 const char *name, struct resource *r)
{
         u64 taddr;

         if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
                 return -EINVAL;
         taddr = of_translate_address(dev, addrp);
         if (taddr == OF_BAD_ADDR)
                 return -EINVAL;
         memset(r, 0, sizeof(struct resource));
         if (flags & IORESOURCE_IO) {
                 unsigned long port;

/*****************************************************************/
/*legacy port(< 0x1000) is reserved, and need no translation here*/
/*****************************************************************/
                 if(taddr + size < PCIBIOS_MIN_IO){
                         r->start = taddr;
                         r->end = taddr + size - 1;
                 }


                 else{
                         port = pci_address_to_pio(taddr);
                         if (port == (unsigned long)-1)
                                 return -EINVAL;
                         r->start = port;
                         r->end = port + size - 1;
                 }
         } else {
                 r->start = taddr;
                 r->end = taddr + size - 1;
         }
         r->flags = flags;
         r->name = name ? name : dev->full_name;

         return 0;
}



>
>  >         Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2015/12/31 23:00, Rongrong Zou ??:
>
>
> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
>  >
>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>  > > >> +Example:
>  > > >> +
>  > > >> +        lpc_0: lpc at a01b0000 {
>  > > >> +          #address-cells = <1>;
>  > > >> +          #size-cells = <1>;
>  > > >> +                compatible = "low-pin-count";
>  > > >> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>  > > >> +        };
>  > > >
>  > > > One more thought: please try to stick as closely as possible to the existing
>  > > > ISA binding that is documented at
>  > > >
>  > > > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>  > >  From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
>  > > >
>  > > > In particular, this should cover the possibility of describing both memory
>  > > > and I/O spaces in child devices.
>  > > >
>  > >
>  > > I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"
>  > >
>  > > isa at 1e {
>  > >                                  device_type = "isa";
>  > >                                  #interrupt-cells = <2>;
>  > >                                  #size-cells = <1>;
>  > >                                  #address-cells = <2>;
>  > >                                  reg = <0xf000 0x0 0x0 0x0 0x0>;
>  > >                                  ranges = <0x1 0x0 0x1000000 0x0 0x0
>  > >                                            0x1000>;
>  > >                                  interrupt-parent = <&i8259>;
>  > >
>  > >
>  > >
>  > >                                  rtc at 70 {
>  > >                                          compatible = "pnpPNP,b00";
>  > >                                          reg = <0x1 0x70 0x2>;
>  > >                                  };
>  > >   the isa space in child-node: reg = <0x1 0x70 0x2>;
>  > >   0x1 means IO space, 70 means addr, 0x2 is size.
>  > >   but when i config the following in dts, the ipmi_0 node can't be probed,
>  > >   I think there may be some problems.
>  > >
>  > > lpc_0: lpc at a01b0000 {
>  > >       compatible = "low-pin-count";
>  > >       device_type = "isa";
>  > >       #address-cells = <2>;
>  > >       #size-cells = <1>;
>  > >       reg = <0x0 0xa01b0000 0x0 0x10000>;
>  > >
>  > >       ipmi_0:ipmi at 000000e4{
>  > >               device_type = "ipmi";
>  > >               compatible = "ipmi-bt";
>  > >               reg = <0x1 0x000000e4 0x4>;
>  > > };
>  >
>  > The DT sample above looks good in principle. I believe what you are missing
>  > here is code in your driver to scan the child nodes to create the platform
>  > devices. of_bus_isa_translate() should work with your definition here
>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>  > resources, so the absence of a ranges property is ok. Maybe all you
>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>  >
>
> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> will be sent later. By the way, it's my another email account use when i at home.

I tried, and there need some additional changes.

isa at a01b0000 {

/*the node name should start with "isa", because of below definition
* static int of_bus_isa_match(struct device_node *np)
* {
*	return !strcmp(np->name, "isa");
* }
*/
	compatible = "low-pin-count";
	device_type = "isa";
	#address-cells = <2>;
	#size-cells = <1>;
	reg = <0x0 0xa01b0000 0x0 0x10000>;
	ranges = <0x1 0x0 0x0 0x0 0x1000>;
/*
*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
*
*/
	ipmi_0:ipmi at 000000e4{
		device_type = "ipmi";
		compatible = "ipmi-bt";
		reg = <0x1 0x000000e4 0x4>;
};

drivers\of\address.c
static int __of_address_to_resource(struct device_node *dev,
                 const __be32 *addrp, u64 size, unsigned int flags,
                 const char *name, struct resource *r)
{
         u64 taddr;

         if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
                 return -EINVAL;
         taddr = of_translate_address(dev, addrp);
         if (taddr == OF_BAD_ADDR)
                 return -EINVAL;
         memset(r, 0, sizeof(struct resource));
         if (flags & IORESOURCE_IO) {
                 unsigned long port;

/*****************************************************************/
/*legacy port(< 0x1000) is reserved, and need no translation here*/
/*****************************************************************/
                 if(taddr + size < PCIBIOS_MIN_IO){
                         r->start = taddr;
                         r->end = taddr + size - 1;
                 }


                 else{
                         port = pci_address_to_pio(taddr);
                         if (port == (unsigned long)-1)
                                 return -EINVAL;
                         r->start = port;
                         r->end = port + size - 1;
                 }
         } else {
                 r->start = taddr;
                 r->end = taddr + size - 1;
         }
         r->flags = flags;
         r->name = name ? name : dev->full_name;

         return 0;
}



>
>  >         Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2015/12/31 23:00, Rongrong Zou 写道:
>
>
> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org <mailto:arnd@arndb.de>>:
>  >
>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>  > > >> +Example:
>  > > >> +
>  > > >> +        lpc_0: lpc@a01b0000 {
>  > > >> +          #address-cells = <1>;
>  > > >> +          #size-cells = <1>;
>  > > >> +                compatible = "low-pin-count";
>  > > >> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>  > > >> +        };
>  > > >
>  > > > One more thought: please try to stick as closely as possible to the existing
>  > > > ISA binding that is documented at
>  > > >
>  > > > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>  > >  From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
>  > > >
>  > > > In particular, this should cover the possibility of describing both memory
>  > > > and I/O spaces in child devices.
>  > > >
>  > >
>  > > I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"
>  > >
>  > > isa@1e {
>  > >                                  device_type = "isa";
>  > >                                  #interrupt-cells = <2>;
>  > >                                  #size-cells = <1>;
>  > >                                  #address-cells = <2>;
>  > >                                  reg = <0xf000 0x0 0x0 0x0 0x0>;
>  > >                                  ranges = <0x1 0x0 0x1000000 0x0 0x0
>  > >                                            0x1000>;
>  > >                                  interrupt-parent = <&i8259>;
>  > >
>  > >
>  > >
>  > >                                  rtc@70 {
>  > >                                          compatible = "pnpPNP,b00";
>  > >                                          reg = <0x1 0x70 0x2>;
>  > >                                  };
>  > >   the isa space in child-node: reg = <0x1 0x70 0x2>;
>  > >   0x1 means IO space, 70 means addr, 0x2 is size.
>  > >   but when i config the following in dts, the ipmi_0 node can't be probed,
>  > >   I think there may be some problems.
>  > >
>  > > lpc_0: lpc@a01b0000 {
>  > >       compatible = "low-pin-count";
>  > >       device_type = "isa";
>  > >       #address-cells = <2>;
>  > >       #size-cells = <1>;
>  > >       reg = <0x0 0xa01b0000 0x0 0x10000>;
>  > >
>  > >       ipmi_0:ipmi@000000e4{
>  > >               device_type = "ipmi";
>  > >               compatible = "ipmi-bt";
>  > >               reg = <0x1 0x000000e4 0x4>;
>  > > };
>  >
>  > The DT sample above looks good in principle. I believe what you are missing
>  > here is code in your driver to scan the child nodes to create the platform
>  > devices. of_bus_isa_translate() should work with your definition here
>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>  > resources, so the absence of a ranges property is ok. Maybe all you
>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>  >
>
> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> will be sent later. By the way, it's my another email account use when i at home.

I tried, and there need some additional changes.

isa@a01b0000 {

/*the node name should start with "isa", because of below definition
* static int of_bus_isa_match(struct device_node *np)
* {
*	return !strcmp(np->name, "isa");
* }
*/
	compatible = "low-pin-count";
	device_type = "isa";
	#address-cells = <2>;
	#size-cells = <1>;
	reg = <0x0 0xa01b0000 0x0 0x10000>;
	ranges = <0x1 0x0 0x0 0x0 0x1000>;
/*
*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
*
*/
	ipmi_0:ipmi@000000e4{
		device_type = "ipmi";
		compatible = "ipmi-bt";
		reg = <0x1 0x000000e4 0x4>;
};

drivers\of\address.c
static int __of_address_to_resource(struct device_node *dev,
                 const __be32 *addrp, u64 size, unsigned int flags,
                 const char *name, struct resource *r)
{
         u64 taddr;

         if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
                 return -EINVAL;
         taddr = of_translate_address(dev, addrp);
         if (taddr == OF_BAD_ADDR)
                 return -EINVAL;
         memset(r, 0, sizeof(struct resource));
         if (flags & IORESOURCE_IO) {
                 unsigned long port;

/*****************************************************************/
/*legacy port(< 0x1000) is reserved, and need no translation here*/
/*****************************************************************/
                 if(taddr + size < PCIBIOS_MIN_IO){
                         r->start = taddr;
                         r->end = taddr + size - 1;
                 }


                 else{
                         port = pci_address_to_pio(taddr);
                         if (port == (unsigned long)-1)
                                 return -EINVAL;
                         r->start = port;
                         r->end = port + size - 1;
                 }
         } else {
                 r->start = taddr;
                 r->end = taddr + size - 1;
         }
         r->flags = flags;
         r->name = name ? name : dev->full_name;

         return 0;
}



>
>  >         Arnd

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> 在 2015/12/31 23:00, Rongrong Zou 写道:
> > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
> >  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >  >
> >  > The DT sample above looks good in principle. I believe what you are missing
> >  > here is code in your driver to scan the child nodes to create the platform
> >  > devices. of_bus_isa_translate() should work with your definition here
> >  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >  > resources, so the absence of a ranges property is ok. Maybe all you
> >  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >  >
> >
> > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > will be sent later. By the way, it's my another email account use when i at home.
> 
> I tried, and there need some additional changes.
> 
> isa@a01b0000 {
> 
> /*the node name should start with "isa", because of below definition
> * static int of_bus_isa_match(struct device_node *np)
> * {
> *	return !strcmp(np->name, "isa");
> * }

Looks good. It would be nicer to match on device_type than on name,
but this is ancient code and it's probably best not to touch it
so we don't accidentally break some old SPARC or PPC system.

> */
> 	compatible = "low-pin-count";
> 	device_type = "isa";
> 	#address-cells = <2>;
> 	#size-cells = <1>;
> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> /*
> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> *
> */
> 	ipmi_0:ipmi@000000e4{
> 		device_type = "ipmi";
> 		compatible = "ipmi-bt";
> 		reg = <0x1 0x000000e4 0x4>;
> };
> 

This looks wrong: the property above says that the I/O port range is
translated to MMIO address 0x00000000 to 0x00010000, which is not
true on your hardware. I think this needs to be changed in the code
so the ranges property is not required for I/O ports.

> drivers\of\address.c
> static int __of_address_to_resource(struct device_node *dev,
>                  const __be32 *addrp, u64 size, unsigned int flags,
>                  const char *name, struct resource *r)
> {
>          u64 taddr;
> 
>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>                  return -EINVAL;
>          taddr = of_translate_address(dev, addrp);
>          if (taddr == OF_BAD_ADDR)
>                  return -EINVAL;
>          memset(r, 0, sizeof(struct resource));
>          if (flags & IORESOURCE_IO) {
>                  unsigned long port;
> 
> /*****************************************************************/
> /*legacy port(< 0x1000) is reserved, and need no translation here*/
> /*****************************************************************/
>                  if(taddr + size < PCIBIOS_MIN_IO){
>                          r->start = taddr;
>                          r->end = taddr + size - 1;
>                  }

I don't like having a special case based on the address here,
the same kind of hack might be needed for PCI I/O spaces in
hardware that uses an indirect method like your LPC bus
does, and the code above will not work on any LPC implementation
that correctly multiplexes its I/O ports with the first PCI domain.

I think it would be better to avoid translating the port into
a physical address to start with just to translate it back into
a port number, what we need instead is the offset between the
bus specific port number and the linux port number. I've added
Liviu to Cc, he wrote this code originally and may have some idea
of how we could do that.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> ? 2015/12/31 23:00, Rongrong Zou ??:
> > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
> >  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
> >  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >  >
> >  > The DT sample above looks good in principle. I believe what you are missing
> >  > here is code in your driver to scan the child nodes to create the platform
> >  > devices. of_bus_isa_translate() should work with your definition here
> >  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >  > resources, so the absence of a ranges property is ok. Maybe all you
> >  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >  >
> >
> > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > will be sent later. By the way, it's my another email account use when i at home.
> 
> I tried, and there need some additional changes.
> 
> isa at a01b0000 {
> 
> /*the node name should start with "isa", because of below definition
> * static int of_bus_isa_match(struct device_node *np)
> * {
> *	return !strcmp(np->name, "isa");
> * }

Looks good. It would be nicer to match on device_type than on name,
but this is ancient code and it's probably best not to touch it
so we don't accidentally break some old SPARC or PPC system.

> */
> 	compatible = "low-pin-count";
> 	device_type = "isa";
> 	#address-cells = <2>;
> 	#size-cells = <1>;
> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> /*
> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> *
> */
> 	ipmi_0:ipmi at 000000e4{
> 		device_type = "ipmi";
> 		compatible = "ipmi-bt";
> 		reg = <0x1 0x000000e4 0x4>;
> };
> 

This looks wrong: the property above says that the I/O port range is
translated to MMIO address 0x00000000 to 0x00010000, which is not
true on your hardware. I think this needs to be changed in the code
so the ranges property is not required for I/O ports.

> drivers\of\address.c
> static int __of_address_to_resource(struct device_node *dev,
>                  const __be32 *addrp, u64 size, unsigned int flags,
>                  const char *name, struct resource *r)
> {
>          u64 taddr;
> 
>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>                  return -EINVAL;
>          taddr = of_translate_address(dev, addrp);
>          if (taddr == OF_BAD_ADDR)
>                  return -EINVAL;
>          memset(r, 0, sizeof(struct resource));
>          if (flags & IORESOURCE_IO) {
>                  unsigned long port;
> 
> /*****************************************************************/
> /*legacy port(< 0x1000) is reserved, and need no translation here*/
> /*****************************************************************/
>                  if(taddr + size < PCIBIOS_MIN_IO){
>                          r->start = taddr;
>                          r->end = taddr + size - 1;
>                  }

I don't like having a special case based on the address here,
the same kind of hack might be needed for PCI I/O spaces in
hardware that uses an indirect method like your LPC bus
does, and the code above will not work on any LPC implementation
that correctly multiplexes its I/O ports with the first PCI domain.

I think it would be better to avoid translating the port into
a physical address to start with just to translate it back into
a port number, what we need instead is the offset between the
bus specific port number and the linux port number. I've added
Liviu to Cc, he wrote this code originally and may have some idea
of how we could do that.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> 在 2015/12/31 23:00, Rongrong Zou 写道:
> > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org <mailto:arnd@arndb.de>>:
> >  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >  >
> >  > The DT sample above looks good in principle. I believe what you are missing
> >  > here is code in your driver to scan the child nodes to create the platform
> >  > devices. of_bus_isa_translate() should work with your definition here
> >  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >  > resources, so the absence of a ranges property is ok. Maybe all you
> >  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >  >
> >
> > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > will be sent later. By the way, it's my another email account use when i at home.
> 
> I tried, and there need some additional changes.
> 
> isa@a01b0000 {
> 
> /*the node name should start with "isa", because of below definition
> * static int of_bus_isa_match(struct device_node *np)
> * {
> *	return !strcmp(np->name, "isa");
> * }

Looks good. It would be nicer to match on device_type than on name,
but this is ancient code and it's probably best not to touch it
so we don't accidentally break some old SPARC or PPC system.

> */
> 	compatible = "low-pin-count";
> 	device_type = "isa";
> 	#address-cells = <2>;
> 	#size-cells = <1>;
> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> /*
> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> *
> */
> 	ipmi_0:ipmi@000000e4{
> 		device_type = "ipmi";
> 		compatible = "ipmi-bt";
> 		reg = <0x1 0x000000e4 0x4>;
> };
> 

This looks wrong: the property above says that the I/O port range is
translated to MMIO address 0x00000000 to 0x00010000, which is not
true on your hardware. I think this needs to be changed in the code
so the ranges property is not required for I/O ports.

> drivers\of\address.c
> static int __of_address_to_resource(struct device_node *dev,
>                  const __be32 *addrp, u64 size, unsigned int flags,
>                  const char *name, struct resource *r)
> {
>          u64 taddr;
> 
>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>                  return -EINVAL;
>          taddr = of_translate_address(dev, addrp);
>          if (taddr == OF_BAD_ADDR)
>                  return -EINVAL;
>          memset(r, 0, sizeof(struct resource));
>          if (flags & IORESOURCE_IO) {
>                  unsigned long port;
> 
> /*****************************************************************/
> /*legacy port(< 0x1000) is reserved, and need no translation here*/
> /*****************************************************************/
>                  if(taddr + size < PCIBIOS_MIN_IO){
>                          r->start = taddr;
>                          r->end = taddr + size - 1;
>                  }

I don't like having a special case based on the address here,
the same kind of hack might be needed for PCI I/O spaces in
hardware that uses an indirect method like your LPC bus
does, and the code above will not work on any LPC implementation
that correctly multiplexes its I/O ports with the first PCI domain.

I think it would be better to avoid translating the port into
a physical address to start with just to translate it back into
a port number, what we need instead is the offset between the
bus specific port number and the linux port number. I've added
Liviu to Cc, he wrote this code originally and may have some idea
of how we could do that.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/4 19:13, Arnd Bergmann 写道:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>   >
>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>   > here is code in your driver to scan the child nodes to create the platform
>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>   >
>>>
>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>> will be sent later. By the way, it's my another email account use when i at home.
>>
>> I tried, and there need some additional changes.
>>
>> isa@a01b0000 {
>>
>> /*the node name should start with "isa", because of below definition
>> * static int of_bus_isa_match(struct device_node *np)
>> * {
>> *	return !strcmp(np->name, "isa");
>> * }
>
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
>
>> */
>> 	compatible = "low-pin-count";
>> 	device_type = "isa";
>> 	#address-cells = <2>;
>> 	#size-cells = <1>;
>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>> /*
>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>> *
>> */
>> 	ipmi_0:ipmi@000000e4{
>> 		device_type = "ipmi";
>> 		compatible = "ipmi-bt";
>> 		reg = <0x1 0x000000e4 0x4>;
>> };
>>
>
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.

Ranges property can set empty, but this means 1:1 translation. the I/O 
port range is translated to MMIO address 0x00000001 00000000 to 
0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
I/O port resource from dts.

For ipmi driver, I can get I/O port resource by DMI rather than dts.

>
>> drivers\of\address.c
>> static int __of_address_to_resource(struct device_node *dev,
>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>                   const char *name, struct resource *r)
>> {
>>           u64 taddr;
>>
>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>                   return -EINVAL;
>>           taddr = of_translate_address(dev, addrp);
>>           if (taddr == OF_BAD_ADDR)
>>                   return -EINVAL;
>>           memset(r, 0, sizeof(struct resource));
>>           if (flags & IORESOURCE_IO) {
>>                   unsigned long port;
>>
>> /*****************************************************************/
>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>> /*****************************************************************/
>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>                           r->start = taddr;
>>                           r->end = taddr + size - 1;
>>                   }
>
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
>
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.
>
> 	Arnd
>

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/4 19:13, Arnd Bergmann ??:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>   > > ? 2015/12/30 17:06, Arnd Bergmann ??:
>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>   >
>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>   > here is code in your driver to scan the child nodes to create the platform
>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>   >
>>>
>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>> will be sent later. By the way, it's my another email account use when i at home.
>>
>> I tried, and there need some additional changes.
>>
>> isa at a01b0000 {
>>
>> /*the node name should start with "isa", because of below definition
>> * static int of_bus_isa_match(struct device_node *np)
>> * {
>> *	return !strcmp(np->name, "isa");
>> * }
>
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
>
>> */
>> 	compatible = "low-pin-count";
>> 	device_type = "isa";
>> 	#address-cells = <2>;
>> 	#size-cells = <1>;
>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>> /*
>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>> *
>> */
>> 	ipmi_0:ipmi at 000000e4{
>> 		device_type = "ipmi";
>> 		compatible = "ipmi-bt";
>> 		reg = <0x1 0x000000e4 0x4>;
>> };
>>
>
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.

Ranges property can set empty, but this means 1:1 translation. the I/O 
port range is translated to MMIO address 0x00000001 00000000 to 
0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
I/O port resource from dts.

For ipmi driver, I can get I/O port resource by DMI rather than dts.

>
>> drivers\of\address.c
>> static int __of_address_to_resource(struct device_node *dev,
>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>                   const char *name, struct resource *r)
>> {
>>           u64 taddr;
>>
>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>                   return -EINVAL;
>>           taddr = of_translate_address(dev, addrp);
>>           if (taddr == OF_BAD_ADDR)
>>                   return -EINVAL;
>>           memset(r, 0, sizeof(struct resource));
>>           if (flags & IORESOURCE_IO) {
>>                   unsigned long port;
>>
>> /*****************************************************************/
>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>> /*****************************************************************/
>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>                           r->start = taddr;
>>                           r->end = taddr + size - 1;
>>                   }
>
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
>
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.
>
> 	Arnd
>

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/4 19:13, Arnd Bergmann 写道:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org <mailto:arnd@arndb.de>>:
>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>   >
>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>   > here is code in your driver to scan the child nodes to create the platform
>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>   >
>>>
>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>> will be sent later. By the way, it's my another email account use when i at home.
>>
>> I tried, and there need some additional changes.
>>
>> isa@a01b0000 {
>>
>> /*the node name should start with "isa", because of below definition
>> * static int of_bus_isa_match(struct device_node *np)
>> * {
>> *	return !strcmp(np->name, "isa");
>> * }
>
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
>
>> */
>> 	compatible = "low-pin-count";
>> 	device_type = "isa";
>> 	#address-cells = <2>;
>> 	#size-cells = <1>;
>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>> /*
>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>> *
>> */
>> 	ipmi_0:ipmi@000000e4{
>> 		device_type = "ipmi";
>> 		compatible = "ipmi-bt";
>> 		reg = <0x1 0x000000e4 0x4>;
>> };
>>
>
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.

Ranges property can set empty, but this means 1:1 translation. the I/O 
port range is translated to MMIO address 0x00000001 00000000 to 
0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
I/O port resource from dts.

For ipmi driver, I can get I/O port resource by DMI rather than dts.

>
>> drivers\of\address.c
>> static int __of_address_to_resource(struct device_node *dev,
>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>                   const char *name, struct resource *r)
>> {
>>           u64 taddr;
>>
>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>                   return -EINVAL;
>>           taddr = of_translate_address(dev, addrp);
>>           if (taddr == OF_BAD_ADDR)
>>                   return -EINVAL;
>>           memset(r, 0, sizeof(struct resource));
>>           if (flags & IORESOURCE_IO) {
>>                   unsigned long port;
>>
>> /*****************************************************************/
>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>> /*****************************************************************/
>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>                           r->start = taddr;
>>                           r->end = taddr + size - 1;
>>                   }
>
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
>
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.
>
> 	Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
> 在 2016/1/4 19:13, Arnd Bergmann 写道:
> > On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >> 在 2015/12/31 23:00, Rongrong Zou 写道:
> >> */
> >>      compatible = "low-pin-count";
> >>      device_type = "isa";
> >>      #address-cells = <2>;
> >>      #size-cells = <1>;
> >>      reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>      ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >> /*
> >> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >> *
> >> */
> >>      ipmi_0:ipmi@000000e4{
> >>              device_type = "ipmi";
> >>              compatible = "ipmi-bt";
> >>              reg = <0x1 0x000000e4 0x4>;
> >> };
> >>
> >
> > This looks wrong: the property above says that the I/O port range is
> > translated to MMIO address 0x00000000 to 0x00010000, which is not
> > true on your hardware. I think this needs to be changed in the code
> > so the ranges property is not required for I/O ports.
> 
> Ranges property can set empty, but this means 1:1 translation. the I/O 
> port range is translated to MMIO address 0x00000001 00000000 to 
> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
> I/O port resource from dts.

As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.

> For ipmi driver, I can get I/O port resource by DMI rather than dts.

No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
> ? 2016/1/4 19:13, Arnd Bergmann ??:
> > On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >> ? 2015/12/31 23:00, Rongrong Zou ??:
> >> */
> >>      compatible = "low-pin-count";
> >>      device_type = "isa";
> >>      #address-cells = <2>;
> >>      #size-cells = <1>;
> >>      reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>      ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >> /*
> >> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >> *
> >> */
> >>      ipmi_0:ipmi at 000000e4{
> >>              device_type = "ipmi";
> >>              compatible = "ipmi-bt";
> >>              reg = <0x1 0x000000e4 0x4>;
> >> };
> >>
> >
> > This looks wrong: the property above says that the I/O port range is
> > translated to MMIO address 0x00000000 to 0x00010000, which is not
> > true on your hardware. I think this needs to be changed in the code
> > so the ranges property is not required for I/O ports.
> 
> Ranges property can set empty, but this means 1:1 translation. the I/O 
> port range is translated to MMIO address 0x00000001 00000000 to 
> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
> I/O port resource from dts.

As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.

> For ipmi driver, I can get I/O port resource by DMI rather than dts.

No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
> 在 2016/1/4 19:13, Arnd Bergmann 写道:
> > On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >> 在 2015/12/31 23:00, Rongrong Zou 写道:
> >> */
> >>      compatible = "low-pin-count";
> >>      device_type = "isa";
> >>      #address-cells = <2>;
> >>      #size-cells = <1>;
> >>      reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>      ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >> /*
> >> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >> *
> >> */
> >>      ipmi_0:ipmi@000000e4{
> >>              device_type = "ipmi";
> >>              compatible = "ipmi-bt";
> >>              reg = <0x1 0x000000e4 0x4>;
> >> };
> >>
> >
> > This looks wrong: the property above says that the I/O port range is
> > translated to MMIO address 0x00000000 to 0x00010000, which is not
> > true on your hardware. I think this needs to be changed in the code
> > so the ranges property is not required for I/O ports.
> 
> Ranges property can set empty, but this means 1:1 translation. the I/O 
> port range is translated to MMIO address 0x00000001 00000000 to 
> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy 
> I/O port resource from dts.

As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.

> For ipmi driver, I can get I/O port resource by DMI rather than dts.

No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/5 0:34, Arnd Bergmann 写道:
> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>> */
>>>>       compatible = "low-pin-count";
>>>>       device_type = "isa";
>>>>       #address-cells = <2>;
>>>>       #size-cells = <1>;
>>>>       reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>       ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>> /*
>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>> *
>>>> */
>>>>       ipmi_0:ipmi@000000e4{
>>>>               device_type = "ipmi";
>>>>               compatible = "ipmi-bt";
>>>>               reg = <0x1 0x000000e4 0x4>;
>>>> };
>>>>
>>>
>>> This looks wrong: the property above says that the I/O port range is
>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>> true on your hardware. I think this needs to be changed in the code
>>> so the ranges property is not required for I/O ports.
>>
>> Ranges property can set empty, but this means 1:1 translation. the I/O
>> port range is translated to MMIO address 0x00000001 00000000 to
>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>> I/O port resource from dts.
>
> As I said, nothing should really require the ranges property here, unless
> you have a valid IORESOURCE_MEM translation. The code that requires
> the ranges to be present is wrong.
>

I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.

/**
  * of_address_to_resource - Translate device tree address and return as resource
  *
  * Note that if your address is a PIO address, the conversion will fail if
  * the physical address can't be internally converted to an IO token with
  * pci_address_to_pio(), that is because it's either called to early or it
  * can't be matched to any host bridge IO space
  */
int of_address_to_resource(struct device_node *dev, int index,
			   struct resource *r)

>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>
> No, the ipmi driver uses the resource that belongs to the platform
> device already, you can't rely on DMI data to be present there.

Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.


>
> 	Arnd
>
> .
>

Thanks,

Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/5 0:34, Arnd Bergmann ??:
> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>> ? 2016/1/4 19:13, Arnd Bergmann ??:
>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>> */
>>>>       compatible = "low-pin-count";
>>>>       device_type = "isa";
>>>>       #address-cells = <2>;
>>>>       #size-cells = <1>;
>>>>       reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>       ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>> /*
>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>> *
>>>> */
>>>>       ipmi_0:ipmi at 000000e4{
>>>>               device_type = "ipmi";
>>>>               compatible = "ipmi-bt";
>>>>               reg = <0x1 0x000000e4 0x4>;
>>>> };
>>>>
>>>
>>> This looks wrong: the property above says that the I/O port range is
>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>> true on your hardware. I think this needs to be changed in the code
>>> so the ranges property is not required for I/O ports.
>>
>> Ranges property can set empty, but this means 1:1 translation. the I/O
>> port range is translated to MMIO address 0x00000001 00000000 to
>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>> I/O port resource from dts.
>
> As I said, nothing should really require the ranges property here, unless
> you have a valid IORESOURCE_MEM translation. The code that requires
> the ranges to be present is wrong.
>

I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.

/**
  * of_address_to_resource - Translate device tree address and return as resource
  *
  * Note that if your address is a PIO address, the conversion will fail if
  * the physical address can't be internally converted to an IO token with
  * pci_address_to_pio(), that is because it's either called to early or it
  * can't be matched to any host bridge IO space
  */
int of_address_to_resource(struct device_node *dev, int index,
			   struct resource *r)

>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>
> No, the ipmi driver uses the resource that belongs to the platform
> device already, you can't rely on DMI data to be present there.

Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.


>
> 	Arnd
>
> .
>

Thanks,

Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/5 0:34, Arnd Bergmann 写道:
> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>> */
>>>>       compatible = "low-pin-count";
>>>>       device_type = "isa";
>>>>       #address-cells = <2>;
>>>>       #size-cells = <1>;
>>>>       reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>       ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>> /*
>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>> *
>>>> */
>>>>       ipmi_0:ipmi@000000e4{
>>>>               device_type = "ipmi";
>>>>               compatible = "ipmi-bt";
>>>>               reg = <0x1 0x000000e4 0x4>;
>>>> };
>>>>
>>>
>>> This looks wrong: the property above says that the I/O port range is
>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>> true on your hardware. I think this needs to be changed in the code
>>> so the ranges property is not required for I/O ports.
>>
>> Ranges property can set empty, but this means 1:1 translation. the I/O
>> port range is translated to MMIO address 0x00000001 00000000 to
>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>> I/O port resource from dts.
>
> As I said, nothing should really require the ranges property here, unless
> you have a valid IORESOURCE_MEM translation. The code that requires
> the ranges to be present is wrong.
>

I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.

/**
  * of_address_to_resource - Translate device tree address and return as resource
  *
  * Note that if your address is a PIO address, the conversion will fail if
  * the physical address can't be internally converted to an IO token with
  * pci_address_to_pio(), that is because it's either called to early or it
  * can't be matched to any host bridge IO space
  */
int of_address_to_resource(struct device_node *dev, int index,
			   struct resource *r)

>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>
> No, the ipmi driver uses the resource that belongs to the platform
> device already, you can't rely on DMI data to be present there.

Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.


>
> 	Arnd
>
> .
>

Thanks,

Rongrong

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
> 在 2016/1/5 0:34, Arnd Bergmann 写道:
> > On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
> >> 在 2016/1/4 19:13, Arnd Bergmann 写道:
> >>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
> >> Ranges property can set empty, but this means 1:1 translation. the I/O
> >> port range is translated to MMIO address 0x00000001 00000000 to
> >> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
> >> I/O port resource from dts.
> >
> > As I said, nothing should really require the ranges property here, unless
> > you have a valid IORESOURCE_MEM translation. The code that requires
> > the ranges to be present is wrong.
> >
> 
> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
> must get resource by calling of_address_to_resource(), which have to call
> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
> better idea for this now. Maybe liviu can give me some opinions.

I think on x86 it works (or used to work, few people use open firmware on
x86 these days, and it may be broken), and the pci_address_to_pio() call
behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
memory mapped I/O addresses, they have their own way of accessing them
just like your platform.

> /**
>   * of_address_to_resource - Translate device tree address and return as resource
>   *
>   * Note that if your address is a PIO address, the conversion will fail if
>   * the physical address can't be internally converted to an IO token with
>   * pci_address_to_pio(), that is because it's either called to early or it
>   * can't be matched to any host bridge IO space
>   */
> int of_address_to_resource(struct device_node *dev, int index,
> 			   struct resource *r)

The problem here seems to be that the code assumes that either the I/O ports
are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
it because now we can have the combination of the two.

> >> For ipmi driver, I can get I/O port resource by DMI rather than dts.
> >
> > No, the ipmi driver uses the resource that belongs to the platform
> > device already, you can't rely on DMI data to be present there.
> 
> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
> openfirmware and a few other), I think we just use one of them, not all of them.
> It depend on vendor's hardware solution actually.

I don't think we should mix multiple methods here: if the bus is described
in DT, all its children should be there as well. Otherwise you get into problems
e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
for one or more of them have an offset to the bus specific addresses.

The bus probe code decides what the Linux I/O port numbers are, but DMI
and other methods have no idea of the mapping. As long as there is only
one instance, using the first 0x1000 addresses with a 1:1 mapping saves
us a bit of trouble, but I'd be worried about relying on that assumption
too much.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
> ? 2016/1/5 0:34, Arnd Bergmann ??:
> > On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
> >> ? 2016/1/4 19:13, Arnd Bergmann ??:
> >>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>> ? 2015/12/31 23:00, Rongrong Zou ??:
> >> Ranges property can set empty, but this means 1:1 translation. the I/O
> >> port range is translated to MMIO address 0x00000001 00000000 to
> >> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
> >> I/O port resource from dts.
> >
> > As I said, nothing should really require the ranges property here, unless
> > you have a valid IORESOURCE_MEM translation. The code that requires
> > the ranges to be present is wrong.
> >
> 
> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
> must get resource by calling of_address_to_resource(), which have to call
> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
> better idea for this now. Maybe liviu can give me some opinions.

I think on x86 it works (or used to work, few people use open firmware on
x86 these days, and it may be broken), and the pci_address_to_pio() call
behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
memory mapped I/O addresses, they have their own way of accessing them
just like your platform.

> /**
>   * of_address_to_resource - Translate device tree address and return as resource
>   *
>   * Note that if your address is a PIO address, the conversion will fail if
>   * the physical address can't be internally converted to an IO token with
>   * pci_address_to_pio(), that is because it's either called to early or it
>   * can't be matched to any host bridge IO space
>   */
> int of_address_to_resource(struct device_node *dev, int index,
> 			   struct resource *r)

The problem here seems to be that the code assumes that either the I/O ports
are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
it because now we can have the combination of the two.

> >> For ipmi driver, I can get I/O port resource by DMI rather than dts.
> >
> > No, the ipmi driver uses the resource that belongs to the platform
> > device already, you can't rely on DMI data to be present there.
> 
> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
> openfirmware and a few other), I think we just use one of them, not all of them.
> It depend on vendor's hardware solution actually.

I don't think we should mix multiple methods here: if the bus is described
in DT, all its children should be there as well. Otherwise you get into problems
e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
for one or more of them have an offset to the bus specific addresses.

The bus probe code decides what the Linux I/O port numbers are, but DMI
and other methods have no idea of the mapping. As long as there is only
one instance, using the first 0x1000 addresses with a 1:1 mapping saves
us a bit of trouble, but I'd be worried about relying on that assumption
too much.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/5 20:19, Arnd Bergmann 写道:
> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>> I/O port resource from dts.
>>>
>>> As I said, nothing should really require the ranges property here, unless
>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>> the ranges to be present is wrong.
>>>
>>
>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>> must get resource by calling of_address_to_resource(), which have to call
>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>> better idea for this now. Maybe liviu can give me some opinions.
>
> I think on x86 it works (or used to work, few people use open firmware on
> x86 these days, and it may be broken), and the pci_address_to_pio() call
> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
> memory mapped I/O addresses, they have their own way of accessing them
> just like your platform.
>
>> /**
>>    * of_address_to_resource - Translate device tree address and return as resource
>>    *
>>    * Note that if your address is a PIO address, the conversion will fail if
>>    * the physical address can't be internally converted to an IO token with
>>    * pci_address_to_pio(), that is because it's either called to early or it
>>    * can't be matched to any host bridge IO space
>>    */
>> int of_address_to_resource(struct device_node *dev, int index,
>> 			   struct resource *r)
>
> The problem here seems to be that the code assumes that either the I/O ports
> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
> it because now we can have the combination of the two.


I am considering the following solution:

Adding unmapped isa io functions in

drivers/of/address.c,

static LIST_HEAD(legacy_io_range_list);
int isa_register_io_range(phys_addr_t addr, resource_size_t size);

/* before I call isa(LPC) bus driver, the input I/O port must be translated to phys_addr_t
(the least 16bit means port addr on bus, the second 16bit means bus id)*/

phys_addr_t isa_pio_to_bus_addr(unsigned long pio);

/* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
unsigned long isa_bus_addr_to_pio(phys_addr_t address);

drivers/bus/lpc.c

lpc_bus_probe()
{
	isa_register_io_range(phys_addr_t addr, resource_size_t size);
}

inb(unsigned long port)
{
	unsigned short bus;
	phys_addr_t addr;
	/*hit isa port range*/
	if(addr = isa_pio_to_bus_addr(port))
	{
		bus = (addr >> 16) & 0xffff;

		call lpc driver with addr;
		return lpc_read_byte(bus, addr);
	}
	else /*not hit*/
	{
		return readb(PCI_IOBASE + port);
	}
}



>
>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>
>>> No, the ipmi driver uses the resource that belongs to the platform
>>> device already, you can't rely on DMI data to be present there.
>>
>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>> openfirmware and a few other), I think we just use one of them, not all of them.
>> It depend on vendor's hardware solution actually.
>
> I don't think we should mix multiple methods here: if the bus is described
> in DT, all its children should be there as well. Otherwise you get into problems
> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
> for one or more of them have an offset to the bus specific addresses.
>
> The bus probe code decides what the Linux I/O port numbers are, but DMI
> and other methods have no idea of the mapping. As long as there is only
> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
> us a bit of trouble, but I'd be worried about relying on that assumption
> too much.
>
> 	Arnd
>
>
> .
>

Thanks,

Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/5 20:19, Arnd Bergmann ??:
> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>> ? 2016/1/5 0:34, Arnd Bergmann ??:
>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>> ? 2016/1/4 19:13, Arnd Bergmann ??:
>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>> I/O port resource from dts.
>>>
>>> As I said, nothing should really require the ranges property here, unless
>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>> the ranges to be present is wrong.
>>>
>>
>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>> must get resource by calling of_address_to_resource(), which have to call
>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>> better idea for this now. Maybe liviu can give me some opinions.
>
> I think on x86 it works (or used to work, few people use open firmware on
> x86 these days, and it may be broken), and the pci_address_to_pio() call
> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
> memory mapped I/O addresses, they have their own way of accessing them
> just like your platform.
>
>> /**
>>    * of_address_to_resource - Translate device tree address and return as resource
>>    *
>>    * Note that if your address is a PIO address, the conversion will fail if
>>    * the physical address can't be internally converted to an IO token with
>>    * pci_address_to_pio(), that is because it's either called to early or it
>>    * can't be matched to any host bridge IO space
>>    */
>> int of_address_to_resource(struct device_node *dev, int index,
>> 			   struct resource *r)
>
> The problem here seems to be that the code assumes that either the I/O ports
> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
> it because now we can have the combination of the two.


I am considering the following solution:

Adding unmapped isa io functions in

drivers/of/address.c,

static LIST_HEAD(legacy_io_range_list);
int isa_register_io_range(phys_addr_t addr, resource_size_t size);

/* before I call isa(LPC) bus driver, the input I/O port must be translated to phys_addr_t
(the least 16bit means port addr on bus, the second 16bit means bus id)*/

phys_addr_t isa_pio_to_bus_addr(unsigned long pio);

/* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
unsigned long isa_bus_addr_to_pio(phys_addr_t address);

drivers/bus/lpc.c

lpc_bus_probe()
{
	isa_register_io_range(phys_addr_t addr, resource_size_t size);
}

inb(unsigned long port)
{
	unsigned short bus;
	phys_addr_t addr;
	/*hit isa port range*/
	if(addr = isa_pio_to_bus_addr(port))
	{
		bus = (addr >> 16) & 0xffff;

		call lpc driver with addr;
		return lpc_read_byte(bus, addr);
	}
	else /*not hit*/
	{
		return readb(PCI_IOBASE + port);
	}
}



>
>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>
>>> No, the ipmi driver uses the resource that belongs to the platform
>>> device already, you can't rely on DMI data to be present there.
>>
>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>> openfirmware and a few other), I think we just use one of them, not all of them.
>> It depend on vendor's hardware solution actually.
>
> I don't think we should mix multiple methods here: if the bus is described
> in DT, all its children should be there as well. Otherwise you get into problems
> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
> for one or more of them have an offset to the bus specific addresses.
>
> The bus probe code decides what the Linux I/O port numbers are, but DMI
> and other methods have no idea of the mapping. As long as there is only
> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
> us a bit of trouble, but I'd be worried about relying on that assumption
> too much.
>
> 	Arnd
>
>
> .
>

Thanks,

Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/5 20:19, Arnd Bergmann 写道:
> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>> I/O port resource from dts.
>>>
>>> As I said, nothing should really require the ranges property here, unless
>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>> the ranges to be present is wrong.
>>>
>>
>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>> must get resource by calling of_address_to_resource(), which have to call
>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>> better idea for this now. Maybe liviu can give me some opinions.
>
> I think on x86 it works (or used to work, few people use open firmware on
> x86 these days, and it may be broken), and the pci_address_to_pio() call
> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
> memory mapped I/O addresses, they have their own way of accessing them
> just like your platform.
>
>> /**
>>    * of_address_to_resource - Translate device tree address and return as resource
>>    *
>>    * Note that if your address is a PIO address, the conversion will fail if
>>    * the physical address can't be internally converted to an IO token with
>>    * pci_address_to_pio(), that is because it's either called to early or it
>>    * can't be matched to any host bridge IO space
>>    */
>> int of_address_to_resource(struct device_node *dev, int index,
>> 			   struct resource *r)
>
> The problem here seems to be that the code assumes that either the I/O ports
> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
> it because now we can have the combination of the two.


I am considering the following solution:

Adding unmapped isa io functions in

drivers/of/address.c,

static LIST_HEAD(legacy_io_range_list);
int isa_register_io_range(phys_addr_t addr, resource_size_t size);

/* before I call isa(LPC) bus driver, the input I/O port must be translated to phys_addr_t
(the least 16bit means port addr on bus, the second 16bit means bus id)*/

phys_addr_t isa_pio_to_bus_addr(unsigned long pio);

/* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
unsigned long isa_bus_addr_to_pio(phys_addr_t address);

drivers/bus/lpc.c

lpc_bus_probe()
{
	isa_register_io_range(phys_addr_t addr, resource_size_t size);
}

inb(unsigned long port)
{
	unsigned short bus;
	phys_addr_t addr;
	/*hit isa port range*/
	if(addr = isa_pio_to_bus_addr(port))
	{
		bus = (addr >> 16) & 0xffff;

		call lpc driver with addr;
		return lpc_read_byte(bus, addr);
	}
	else /*not hit*/
	{
		return readb(PCI_IOBASE + port);
	}
}



>
>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>
>>> No, the ipmi driver uses the resource that belongs to the platform
>>> device already, you can't rely on DMI data to be present there.
>>
>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>> openfirmware and a few other), I think we just use one of them, not all of them.
>> It depend on vendor's hardware solution actually.
>
> I don't think we should mix multiple methods here: if the bus is described
> in DT, all its children should be there as well. Otherwise you get into problems
> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
> for one or more of them have an offset to the bus specific addresses.
>
> The bus probe code decides what the Linux I/O port numbers are, but DMI
> and other methods have no idea of the mapping. As long as there is only
> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
> us a bit of trouble, but I'd be worried about relying on that assumption
> too much.
>
> 	Arnd
>
>
> .
>

Thanks,

Rongrong

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/6 21:36, Rongrong Zou 写道:
> 在 2016/1/5 20:19, Arnd Bergmann 写道:
>> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>>> I/O port resource from dts.
>>>>
>>>> As I said, nothing should really require the ranges property here, unless
>>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>>> the ranges to be present is wrong.
>>>>
>>>
>>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>>> must get resource by calling of_address_to_resource(), which have to call
>>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>>> better idea for this now. Maybe liviu can give me some opinions.
>>
>> I think on x86 it works (or used to work, few people use open firmware on
>> x86 these days, and it may be broken), and the pci_address_to_pio() call
>> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
>> memory mapped I/O addresses, they have their own way of accessing them
>> just like your platform.
>>

The big problem is:

The return value of_translate_address can be only an cpu addr,
there is no map from cpuaddr to I/O port in x86 as you said,
we still can't get io resource.

static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
{
...
taddr = of_translate_address(dev, addrp);
...
}


>>> /**
>>>    * of_address_to_resource - Translate device tree address and return as resource
>>>    *
>>>    * Note that if your address is a PIO address, the conversion will fail if
>>>    * the physical address can't be internally converted to an IO token with
>>>    * pci_address_to_pio(), that is because it's either called to early or it
>>>    * can't be matched to any host bridge IO space
>>>    */
>>> int of_address_to_resource(struct device_node *dev, int index,
>>>                struct resource *r)
>>
>> The problem here seems to be that the code assumes that either the I/O ports
>> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
>> it because now we can have the combination of the two.
>
>
> I am considering the following solution:
>
> Adding unmapped isa io functions in
>
> drivers/of/address.c,
>
> static LIST_HEAD(legacy_io_range_list);
> int isa_register_io_range(phys_addr_t addr, resource_size_t size);
>
> /* before I call isa(LPC) bus driver, the input I/O port must be translated to phys_addr_t
> (the least 16bit means port addr on bus, the second 16bit means bus id)*/
>
> phys_addr_t isa_pio_to_bus_addr(unsigned long pio);
>
> /* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
> unsigned long isa_bus_addr_to_pio(phys_addr_t address);
>
> drivers/bus/lpc.c
>
> lpc_bus_probe()
> {
>      isa_register_io_range(phys_addr_t addr, resource_size_t size);
> }
>
> inb(unsigned long port)
> {
>      unsigned short bus;
>      phys_addr_t addr;
>      /*hit isa port range*/
>      if(addr = isa_pio_to_bus_addr(port))
>      {
>          bus = (addr >> 16) & 0xffff;
>
>          call lpc driver with addr;
>          return lpc_read_byte(bus, addr);
>      }
>      else /*not hit*/
>      {
>          return readb(PCI_IOBASE + port);
>      }
> }
>
>
>
>>
>>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>>
>>>> No, the ipmi driver uses the resource that belongs to the platform
>>>> device already, you can't rely on DMI data to be present there.
>>>
>>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>>> openfirmware and a few other), I think we just use one of them, not all of them.
>>> It depend on vendor's hardware solution actually.
>>
>> I don't think we should mix multiple methods here: if the bus is described
>> in DT, all its children should be there as well. Otherwise you get into problems
>> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
>> for one or more of them have an offset to the bus specific addresses.
>>
>> The bus probe code decides what the Linux I/O port numbers are, but DMI
>> and other methods have no idea of the mapping. As long as there is only
>> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
>> us a bit of trouble, but I'd be worried about relying on that assumption
>> too much.
>>
>>     Arnd
>>
>>
>> .

-- 
Thanks,

Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/6 21:36, Rongrong Zou ??:
> ? 2016/1/5 20:19, Arnd Bergmann ??:
>> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>>> ? 2016/1/5 0:34, Arnd Bergmann ??:
>>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>>> ? 2016/1/4 19:13, Arnd Bergmann ??:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>>> I/O port resource from dts.
>>>>
>>>> As I said, nothing should really require the ranges property here, unless
>>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>>> the ranges to be present is wrong.
>>>>
>>>
>>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>>> must get resource by calling of_address_to_resource(), which have to call
>>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>>> better idea for this now. Maybe liviu can give me some opinions.
>>
>> I think on x86 it works (or used to work, few people use open firmware on
>> x86 these days, and it may be broken), and the pci_address_to_pio() call
>> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
>> memory mapped I/O addresses, they have their own way of accessing them
>> just like your platform.
>>

The big problem is:

The return value of_translate_address can be only an cpu addr,
there is no map from cpuaddr to I/O port in x86 as you said,
we still can't get io resource.

static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
{
...
taddr = of_translate_address(dev, addrp);
...
}


>>> /**
>>>    * of_address_to_resource - Translate device tree address and return as resource
>>>    *
>>>    * Note that if your address is a PIO address, the conversion will fail if
>>>    * the physical address can't be internally converted to an IO token with
>>>    * pci_address_to_pio(), that is because it's either called to early or it
>>>    * can't be matched to any host bridge IO space
>>>    */
>>> int of_address_to_resource(struct device_node *dev, int index,
>>>                struct resource *r)
>>
>> The problem here seems to be that the code assumes that either the I/O ports
>> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
>> it because now we can have the combination of the two.
>
>
> I am considering the following solution:
>
> Adding unmapped isa io functions in
>
> drivers/of/address.c,
>
> static LIST_HEAD(legacy_io_range_list);
> int isa_register_io_range(phys_addr_t addr, resource_size_t size);
>
> /* before I call isa(LPC) bus driver, the input I/O port must be translated to phys_addr_t
> (the least 16bit means port addr on bus, the second 16bit means bus id)*/
>
> phys_addr_t isa_pio_to_bus_addr(unsigned long pio);
>
> /* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
> unsigned long isa_bus_addr_to_pio(phys_addr_t address);
>
> drivers/bus/lpc.c
>
> lpc_bus_probe()
> {
>      isa_register_io_range(phys_addr_t addr, resource_size_t size);
> }
>
> inb(unsigned long port)
> {
>      unsigned short bus;
>      phys_addr_t addr;
>      /*hit isa port range*/
>      if(addr = isa_pio_to_bus_addr(port))
>      {
>          bus = (addr >> 16) & 0xffff;
>
>          call lpc driver with addr;
>          return lpc_read_byte(bus, addr);
>      }
>      else /*not hit*/
>      {
>          return readb(PCI_IOBASE + port);
>      }
> }
>
>
>
>>
>>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>>
>>>> No, the ipmi driver uses the resource that belongs to the platform
>>>> device already, you can't rely on DMI data to be present there.
>>>
>>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>>> openfirmware and a few other), I think we just use one of them, not all of them.
>>> It depend on vendor's hardware solution actually.
>>
>> I don't think we should mix multiple methods here: if the bus is described
>> in DT, all its children should be there as well. Otherwise you get into problems
>> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
>> for one or more of them have an offset to the bus specific addresses.
>>
>> The bus probe code decides what the Linux I/O port numbers are, but DMI
>> and other methods have no idea of the mapping. As long as there is only
>> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
>> us a bit of trouble, but I'd be worried about relying on that assumption
>> too much.
>>
>>     Arnd
>>
>>
>> .

-- 
Thanks,

Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/6 21:36, Rongrong Zou 写道:
> 在 2016/1/5 20:19, Arnd Bergmann 写道:
>> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>>> I/O port resource from dts.
>>>>
>>>> As I said, nothing should really require the ranges property here, unless
>>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>>> the ranges to be present is wrong.
>>>>
>>>
>>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>>> must get resource by calling of_address_to_resource(), which have to call
>>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>>> better idea for this now. Maybe liviu can give me some opinions.
>>
>> I think on x86 it works (or used to work, few people use open firmware on
>> x86 these days, and it may be broken), and the pci_address_to_pio() call
>> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
>> memory mapped I/O addresses, they have their own way of accessing them
>> just like your platform.
>>

The big problem is:

The return value of_translate_address can be only an cpu addr,
there is no map from cpuaddr to I/O port in x86 as you said,
we still can't get io resource.

static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
{
...
taddr = of_translate_address(dev, addrp);
...
}


>>> /**
>>>    * of_address_to_resource - Translate device tree address and return as resource
>>>    *
>>>    * Note that if your address is a PIO address, the conversion will fail if
>>>    * the physical address can't be internally converted to an IO token with
>>>    * pci_address_to_pio(), that is because it's either called to early or it
>>>    * can't be matched to any host bridge IO space
>>>    */
>>> int of_address_to_resource(struct device_node *dev, int index,
>>>                struct resource *r)
>>
>> The problem here seems to be that the code assumes that either the I/O ports
>> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
>> it because now we can have the combination of the two.
>
>
> I am considering the following solution:
>
> Adding unmapped isa io functions in
>
> drivers/of/address.c,
>
> static LIST_HEAD(legacy_io_range_list);
> int isa_register_io_range(phys_addr_t addr, resource_size_t size);
>
> /* before I call isa(LPC) bus driver, the input I/O port must be translated to phys_addr_t
> (the least 16bit means port addr on bus, the second 16bit means bus id)*/
>
> phys_addr_t isa_pio_to_bus_addr(unsigned long pio);
>
> /* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
> unsigned long isa_bus_addr_to_pio(phys_addr_t address);
>
> drivers/bus/lpc.c
>
> lpc_bus_probe()
> {
>      isa_register_io_range(phys_addr_t addr, resource_size_t size);
> }
>
> inb(unsigned long port)
> {
>      unsigned short bus;
>      phys_addr_t addr;
>      /*hit isa port range*/
>      if(addr = isa_pio_to_bus_addr(port))
>      {
>          bus = (addr >> 16) & 0xffff;
>
>          call lpc driver with addr;
>          return lpc_read_byte(bus, addr);
>      }
>      else /*not hit*/
>      {
>          return readb(PCI_IOBASE + port);
>      }
> }
>
>
>
>>
>>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>>
>>>> No, the ipmi driver uses the resource that belongs to the platform
>>>> device already, you can't rely on DMI data to be present there.
>>>
>>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>>> openfirmware and a few other), I think we just use one of them, not all of them.
>>> It depend on vendor's hardware solution actually.
>>
>> I don't think we should mix multiple methods here: if the bus is described
>> in DT, all its children should be there as well. Otherwise you get into problems
>> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
>> for one or more of them have an offset to the bus specific addresses.
>>
>> The bus probe code decides what the Linux I/O port numbers are, but DMI
>> and other methods have no idea of the mapping. As long as there is only
>> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
>> us a bit of trouble, but I'd be worried about relying on that assumption
>> too much.
>>
>>     Arnd
>>
>>
>> .

-- 
Thanks,

Rongrong
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rolland Chau]

On 2016/1/5 20:19, Arnd Bergmann wrote:
> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>> I/O port resource from dts.
>>>
>>> As I said, nothing should really require the ranges property here, unless
>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>> the ranges to be present is wrong.
>>>
>>
>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>> must get resource by calling of_address_to_resource(), which have to call
>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>> better idea for this now. Maybe liviu can give me some opinions.
>
> I think on x86 it works (or used to work, few people use open firmware on
> x86 these days, and it may be broken), and the pci_address_to_pio() call
> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
> memory mapped I/O addresses, they have their own way of accessing them
> just like your platform.
>
>> /**
>>    * of_address_to_resource - Translate device tree address and return as resource
>>    *
>>    * Note that if your address is a PIO address, the conversion will fail if
>>    * the physical address can't be internally converted to an IO token with
>>    * pci_address_to_pio(), that is because it's either called to early or it
>>    * can't be matched to any host bridge IO space
>>    */
>> int of_address_to_resource(struct device_node *dev, int index,
>> 			   struct resource *r)
>
> The problem here seems to be that the code assumes that either the I/O ports
> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
> it because now we can have the combination of the two.


Arnd , please take a look at the new solution when you have a moment,thanks.
I modify the "drivers/of/address.c" to address the problem above.

There are some assumptions:

1) ISA(LPC) Like bus must be scanned before PCI.
2) a property "unmapped-size" is introduced to ISA bus DT config, it means the address
  range of the bus. if bus-A have a port range(0-99), bus-B have a port range(0-199), then
the cpu port range (0-99) is reserved for bus-A and cpu port range is reserved for bus-B.
3) It it
---
  drivers/of/address.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++-----
  1 file changed, 70 insertions(+), 6 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 9582c57..d3c71e5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -682,8 +682,16 @@ struct io_range {

  static LIST_HEAD(io_range_list);
  static DEFINE_SPINLOCK(io_range_lock);
+phy_addr_t pci_pio_start = 0;
+EXPORT_SYMBOL(pci_pio_start)
  #endif

+int isa_register_unmapped_io_range(resource_size_t size)
+{
+       pci_pio_start += size;
+}
+
+
  /*
   * Record the PCI IO range (expressed as CPU physical address + size).
   * Return a negative value if an error has occured, zero otherwise
@@ -694,7 +702,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)

  #ifdef PCI_IOBASE
         struct io_range *range;
-       resource_size_t allocated_size = 0;
+       resource_size_t allocated_size = pci_pio_start;

         /* check if the range hasn't been previously recorded */
         spin_lock(&io_range_lock);
@@ -743,7 +751,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)

  #ifdef PCI_IOBASE
         struct io_range *range;
-       resource_size_t allocated_size = 0;
+       resource_size_t allocated_size = pci_pio_start;

         if (pio > IO_SPACE_LIMIT)
                 return address;
@@ -766,7 +774,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
  {
  #ifdef PCI_IOBASE
         struct io_range *res;
-       resource_size_t offset = 0;
+       resource_size_t offset = pci_pio_start;
         unsigned long addr = -1;

         spin_lock(&io_range_lock);
@@ -788,21 +796,77 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
  #endif
  }

+static u64 of_get_unmapped_pio(struct device_node *dev, const __be32 *inaddr)
+{
+       struct device_node *np, *parent = NULL;
+       struct of_bus * bus, *pbus;
+       struct property *p_property;
+       int rlen;
+       u32 size = 0;
+       u32 port_base = 0;
+
+       /*IF NOT I/O port*/
+       if(*(in_addr) != 0x01)
+               return OF_BAD_ADDR;
+       else
+               *in_addr = 0;
+
+       parent = of_get_parent(dev);
+       if(parent == NULL)
+               return result;
+       bus = of_match_bus(parent);
+       if(!strcmp(bus->name, "isa")) {
+               p_property = of_find_property(parent, "ranges", &rlen);
+               /*no ranges property, this is a non-bridged isa bus, and the port on it is unmapped*/
+               if(p_property == NULL) {
+                       for_each_node_by_name(np, "isa") {
+                               if((np != parent) &&
+                                  !of_find_property(parent, "ranges", &rlen) &&
+                                  !of_property_read_u32(parent, "unmapped-size", &size)) {
+                                       port_base += size;
+                               }
+                               else if (np == parent) {
+                                       of_bus_default_translate(in_addr + 1, port_base, 1);
+                                       break;
+                               }
+                               else {
+                                       continue;
+                               }
+                       }
+                       return of_read_number(in_addr, 2);
+
+               }
+
+       }
+       return OF_BAD_ADDR;
+}
+
  static int __of_address_to_resource(struct device_node *dev,
                 const __be32 *addrp, u64 size, unsigned int flags,
                 const char *name, struct resource *r)
  {
         u64 taddr;
+       u8 addr_type = 0;

         if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
                 return -EINVAL;
         taddr = of_translate_address(dev, addrp);
-       if (taddr == OF_BAD_ADDR)
-               return -EINVAL;
+       if (taddr == OF_BAD_ADDR) {
+
+               taddr == of_get_unmapped_pio(dev, addrp);
+               if(taddr == OF_BAD_ADDR)
+                       return -EINVAL
+               else    /*we get unmapped I/O port successfully*/
+                       addr_type = 1;
+       }
+
         memset(r, 0, sizeof(struct resource));
         if (flags & IORESOURCE_IO) {
                 unsigned long port;
-               port = pci_address_to_pio(taddr);
+               if(!addr_type)
+                       port = pci_address_to_pio(taddr);
+               else
+                       port = (unsigned long)taddr;
                 if (port == (unsigned long)-1)
                         return -EINVAL;
                 r->start = port;
-- 


In bus device probe code
static int lpc_probe(struct platform_device *pdev)
{
	...
	if(ret = of_property_read_u32((pdev->dev).of_node, "unmapped-size", &io_ranges))
		return ret;
	
	lpc_dev->bus_size = io_ranges;
	isa_register_io_range(io_ranges);
	ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
	...
	
	return 0;
}

>
>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>
>>> No, the ipmi driver uses the resource that belongs to the platform
>>> device already, you can't rely on DMI data to be present there.
>>
>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>> openfirmware and a few other), I think we just use one of them, not all of them.
>> It depend on vendor's hardware solution actually.
>
> I don't think we should mix multiple methods here: if the bus is described
> in DT, all its children should be there as well. Otherwise you get into problems
> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
> for one or more of them have an offset to the bus specific addresses.
>
> The bus probe code decides what the Linux I/O port numbers are, but DMI
> and other methods have no idea of the mapping. As long as there is only
> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
> us a bit of trouble, but I'd be worried about relying on that assumption
> too much.
>
> 	Arnd
>

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rolland Chau]

On 2016/1/5 20:19, Arnd Bergmann wrote:
> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>> ? 2016/1/5 0:34, Arnd Bergmann ??:
>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>> ? 2016/1/4 19:13, Arnd Bergmann ??:
>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get legacy
>>>> I/O port resource from dts.
>>>
>>> As I said, nothing should really require the ranges property here, unless
>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>> the ranges to be present is wrong.
>>>
>>
>> I think the openfirmware(DT) do not support for those unmapped I/O ports, because I
>> must get resource by calling of_address_to_resource(), which have to call
>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
>> better idea for this now. Maybe liviu can give me some opinions.
>
> I think on x86 it works (or used to work, few people use open firmware on
> x86 these days, and it may be broken), and the pci_address_to_pio() call
> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
> memory mapped I/O addresses, they have their own way of accessing them
> just like your platform.
>
>> /**
>>    * of_address_to_resource - Translate device tree address and return as resource
>>    *
>>    * Note that if your address is a PIO address, the conversion will fail if
>>    * the physical address can't be internally converted to an IO token with
>>    * pci_address_to_pio(), that is because it's either called to early or it
>>    * can't be matched to any host bridge IO space
>>    */
>> int of_address_to_resource(struct device_node *dev, int index,
>> 			   struct resource *r)
>
> The problem here seems to be that the code assumes that either the I/O ports
> are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
> it because now we can have the combination of the two.


Arnd , please take a look at the new solution when you have a moment,thanks.
I modify the "drivers/of/address.c" to address the problem above.

There are some assumptions:

1) ISA(LPC) Like bus must be scanned before PCI.
2) a property "unmapped-size" is introduced to ISA bus DT config, it means the address
  range of the bus. if bus-A have a port range(0-99), bus-B have a port range(0-199), then
the cpu port range (0-99) is reserved for bus-A and cpu port range is reserved for bus-B.
3) It it
---
  drivers/of/address.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++-----
  1 file changed, 70 insertions(+), 6 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 9582c57..d3c71e5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -682,8 +682,16 @@ struct io_range {

  static LIST_HEAD(io_range_list);
  static DEFINE_SPINLOCK(io_range_lock);
+phy_addr_t pci_pio_start = 0;
+EXPORT_SYMBOL(pci_pio_start)
  #endif

+int isa_register_unmapped_io_range(resource_size_t size)
+{
+       pci_pio_start += size;
+}
+
+
  /*
   * Record the PCI IO range (expressed as CPU physical address + size).
   * Return a negative value if an error has occured, zero otherwise
@@ -694,7 +702,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)

  #ifdef PCI_IOBASE
         struct io_range *range;
-       resource_size_t allocated_size = 0;
+       resource_size_t allocated_size = pci_pio_start;

         /* check if the range hasn't been previously recorded */
         spin_lock(&io_range_lock);
@@ -743,7 +751,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)

  #ifdef PCI_IOBASE
         struct io_range *range;
-       resource_size_t allocated_size = 0;
+       resource_size_t allocated_size = pci_pio_start;

         if (pio > IO_SPACE_LIMIT)
                 return address;
@@ -766,7 +774,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
  {
  #ifdef PCI_IOBASE
         struct io_range *res;
-       resource_size_t offset = 0;
+       resource_size_t offset = pci_pio_start;
         unsigned long addr = -1;

         spin_lock(&io_range_lock);
@@ -788,21 +796,77 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
  #endif
  }

+static u64 of_get_unmapped_pio(struct device_node *dev, const __be32 *inaddr)
+{
+       struct device_node *np, *parent = NULL;
+       struct of_bus * bus, *pbus;
+       struct property *p_property;
+       int rlen;
+       u32 size = 0;
+       u32 port_base = 0;
+
+       /*IF NOT I/O port*/
+       if(*(in_addr) != 0x01)
+               return OF_BAD_ADDR;
+       else
+               *in_addr = 0;
+
+       parent = of_get_parent(dev);
+       if(parent == NULL)
+               return result;
+       bus = of_match_bus(parent);
+       if(!strcmp(bus->name, "isa")) {
+               p_property = of_find_property(parent, "ranges", &rlen);
+               /*no ranges property, this is a non-bridged isa bus, and the port on it is unmapped*/
+               if(p_property == NULL) {
+                       for_each_node_by_name(np, "isa") {
+                               if((np != parent) &&
+                                  !of_find_property(parent, "ranges", &rlen) &&
+                                  !of_property_read_u32(parent, "unmapped-size", &size)) {
+                                       port_base += size;
+                               }
+                               else if (np == parent) {
+                                       of_bus_default_translate(in_addr + 1, port_base, 1);
+                                       break;
+                               }
+                               else {
+                                       continue;
+                               }
+                       }
+                       return of_read_number(in_addr, 2);
+
+               }
+
+       }
+       return OF_BAD_ADDR;
+}
+
  static int __of_address_to_resource(struct device_node *dev,
                 const __be32 *addrp, u64 size, unsigned int flags,
                 const char *name, struct resource *r)
  {
         u64 taddr;
+       u8 addr_type = 0;

         if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
                 return -EINVAL;
         taddr = of_translate_address(dev, addrp);
-       if (taddr == OF_BAD_ADDR)
-               return -EINVAL;
+       if (taddr == OF_BAD_ADDR) {
+
+               taddr == of_get_unmapped_pio(dev, addrp);
+               if(taddr == OF_BAD_ADDR)
+                       return -EINVAL
+               else    /*we get unmapped I/O port successfully*/
+                       addr_type = 1;
+       }
+
         memset(r, 0, sizeof(struct resource));
         if (flags & IORESOURCE_IO) {
                 unsigned long port;
-               port = pci_address_to_pio(taddr);
+               if(!addr_type)
+                       port = pci_address_to_pio(taddr);
+               else
+                       port = (unsigned long)taddr;
                 if (port == (unsigned long)-1)
                         return -EINVAL;
                 r->start = port;
-- 


In bus device probe code
static int lpc_probe(struct platform_device *pdev)
{
	...
	if(ret = of_property_read_u32((pdev->dev).of_node, "unmapped-size", &io_ranges))
		return ret;
	
	lpc_dev->bus_size = io_ranges;
	isa_register_io_range(io_ranges);
	ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
	...
	
	return 0;
}

>
>>>> For ipmi driver, I can get I/O port resource by DMI rather than dts.
>>>
>>> No, the ipmi driver uses the resource that belongs to the platform
>>> device already, you can't rely on DMI data to be present there.
>>
>> Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
>> openfirmware and a few other), I think we just use one of them, not all of them.
>> It depend on vendor's hardware solution actually.
>
> I don't think we should mix multiple methods here: if the bus is described
> in DT, all its children should be there as well. Otherwise you get into problems
> e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
> for one or more of them have an offset to the bus specific addresses.
>
> The bus probe code decides what the Linux I/O port numbers are, but DMI
> and other methods have no idea of the mapping. As long as there is only
> one instance, using the first 0x1000 addresses with a 1:1 mapping saves
> us a bit of trouble, but I'd be worried about relying on that assumption
> too much.
>
> 	Arnd
>

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/10 17:29, Rolland Chau 写道:
> On 2016/1/5 20:19, Arnd Bergmann wrote:
>> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get
>>>>> legacy
>>>>> I/O port resource from dts.
>>>>
>>>> As I said, nothing should really require the ranges property here,
>>>> unless
>>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>>> the ranges to be present is wrong.
>>>>
>>>
>>> I think the openfirmware(DT) do not support for those unmapped I/O
>>> ports, because I
>>> must get resource by calling of_address_to_resource(), which have to
>>> call
>>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I
>>> have no
>>> better idea for this now. Maybe liviu can give me some opinions.
>>
>> I think on x86 it works (or used to work, few people use open firmware on
>> x86 these days, and it may be broken), and the pci_address_to_pio() call
>> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
>> memory mapped I/O addresses, they have their own way of accessing them
>> just like your platform.
>>
>>> /**
>>>    * of_address_to_resource - Translate device tree address and
>>> return as resource
>>>    *
>>>    * Note that if your address is a PIO address, the conversion will
>>> fail if
>>>    * the physical address can't be internally converted to an IO
>>> token with
>>>    * pci_address_to_pio(), that is because it's either called to
>>> early or it
>>>    * can't be matched to any host bridge IO space
>>>    */
>>> int of_address_to_resource(struct device_node *dev, int index,
>>>                struct resource *r)
>>
>> The problem here seems to be that the code assumes that either the I/O
>> ports
>> are always mapped or they are never mapped (no PCI_IOBASE). We need to
>> extend
>> it because now we can have the combination of the two.
>
>
> Arnd , please take a look at the new solution when you have a
> moment,thanks.
> I modify the "drivers/of/address.c" to address the problem above.
>
> There are some assumptions:
>
> 1) ISA(LPC) Like bus must be scanned before PCI.
> 2) a property "unmapped-size" is introduced to ISA bus DT config, it
> means the address
>   range of the bus. if bus-A have a port range(0-99), bus-B have a port
> range(0-199), then
> the cpu port range (0-99) is reserved for bus-A and cpu port range (100, 299) is
> reserved for bus-B.
> 3) It it

I sorry, I made a mistake, please ignore 3). And I added the cpu port 
range(100, 299) for bus-B.

> ---
>   drivers/of/address.c | 76
> +++++++++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 9582c57..d3c71e5 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -682,8 +682,16 @@ struct io_range {
>
>   static LIST_HEAD(io_range_list);
>   static DEFINE_SPINLOCK(io_range_lock);
> +phy_addr_t pci_pio_start = 0;
> +EXPORT_SYMBOL(pci_pio_start)
>   #endif
>
> +int isa_register_unmapped_io_range(resource_size_t size)
> +{
> +       pci_pio_start += size;
> +}
> +
> +
>   /*
>    * Record the PCI IO range (expressed as CPU physical address + size).
>    * Return a negative value if an error has occured, zero otherwise
> @@ -694,7 +702,7 @@ int __weak pci_register_io_range(phys_addr_t addr,
> resource_size_t size)
>
>   #ifdef PCI_IOBASE
>          struct io_range *range;
> -       resource_size_t allocated_size = 0;
> +       resource_size_t allocated_size = pci_pio_start;
>
>          /* check if the range hasn't been previously recorded */
>          spin_lock(&io_range_lock);
> @@ -743,7 +751,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>
>   #ifdef PCI_IOBASE
>          struct io_range *range;
> -       resource_size_t allocated_size = 0;
> +       resource_size_t allocated_size = pci_pio_start;
>
>          if (pio > IO_SPACE_LIMIT)
>                  return address;
> @@ -766,7 +774,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t
> address)
>   {
>   #ifdef PCI_IOBASE
>          struct io_range *res;
> -       resource_size_t offset = 0;
> +       resource_size_t offset = pci_pio_start;
>          unsigned long addr = -1;
>
>          spin_lock(&io_range_lock);
> @@ -788,21 +796,77 @@ unsigned long __weak
> pci_address_to_pio(phys_addr_t address)
>   #endif
>   }
>
> +static u64 of_get_unmapped_pio(struct device_node *dev, const __be32
> *inaddr)
> +{
> +       struct device_node *np, *parent = NULL;
> +       struct of_bus * bus, *pbus;
> +       struct property *p_property;
> +       int rlen;
> +       u32 size = 0;
> +       u32 port_base = 0;
> +
> +       /*IF NOT I/O port*/
> +       if(*(in_addr) != 0x01)
> +               return OF_BAD_ADDR;
> +       else
> +               *in_addr = 0;
> +
> +       parent = of_get_parent(dev);
> +       if(parent == NULL)
> +               return result;
> +       bus = of_match_bus(parent);
> +       if(!strcmp(bus->name, "isa")) {
> +               p_property = of_find_property(parent, "ranges", &rlen);
> +               /*no ranges property, this is a non-bridged isa bus, and
> the port on it is unmapped*/
> +               if(p_property == NULL) {
> +                       for_each_node_by_name(np, "isa") {
> +                               if((np != parent) &&
> +                                  !of_find_property(parent, "ranges",
> &rlen) &&
> +                                  !of_property_read_u32(parent,
> "unmapped-size", &size)) {
> +                                       port_base += size;
> +                               }
> +                               else if (np == parent) {
> +                                       of_bus_default_translate(in_addr
> + 1, port_base, 1);
> +                                       break;
> +                               }
> +                               else {
> +                                       continue;
> +                               }
> +                       }
> +                       return of_read_number(in_addr, 2);
> +
> +               }
> +
> +       }
> +       return OF_BAD_ADDR;
> +}
> +
>   static int __of_address_to_resource(struct device_node *dev,
>                  const __be32 *addrp, u64 size, unsigned int flags,
>                  const char *name, struct resource *r)
>   {
>          u64 taddr;
> +       u8 addr_type = 0;
>
>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>                  return -EINVAL;
>          taddr = of_translate_address(dev, addrp);
> -       if (taddr == OF_BAD_ADDR)
> -               return -EINVAL;
> +       if (taddr == OF_BAD_ADDR) {
> +
> +               taddr == of_get_unmapped_pio(dev, addrp);
> +               if(taddr == OF_BAD_ADDR)
> +                       return -EINVAL
> +               else    /*we get unmapped I/O port successfully*/
> +                       addr_type = 1;
> +       }
> +
>          memset(r, 0, sizeof(struct resource));
>          if (flags & IORESOURCE_IO) {
>                  unsigned long port;
> -               port = pci_address_to_pio(taddr);
> +               if(!addr_type)
> +                       port = pci_address_to_pio(taddr);
> +               else
> +                       port = (unsigned long)taddr;
>                  if (port == (unsigned long)-1)
>                          return -EINVAL;
>                  r->start = port;

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/10 17:29, Rolland Chau ??:
> On 2016/1/5 20:19, Arnd Bergmann wrote:
>> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>>> ? 2016/1/5 0:34, Arnd Bergmann ??:
>>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>>> ? 2016/1/4 19:13, Arnd Bergmann ??:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get
>>>>> legacy
>>>>> I/O port resource from dts.
>>>>
>>>> As I said, nothing should really require the ranges property here,
>>>> unless
>>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>>> the ranges to be present is wrong.
>>>>
>>>
>>> I think the openfirmware(DT) do not support for those unmapped I/O
>>> ports, because I
>>> must get resource by calling of_address_to_resource(), which have to
>>> call
>>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I
>>> have no
>>> better idea for this now. Maybe liviu can give me some opinions.
>>
>> I think on x86 it works (or used to work, few people use open firmware on
>> x86 these days, and it may be broken), and the pci_address_to_pio() call
>> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
>> memory mapped I/O addresses, they have their own way of accessing them
>> just like your platform.
>>
>>> /**
>>>    * of_address_to_resource - Translate device tree address and
>>> return as resource
>>>    *
>>>    * Note that if your address is a PIO address, the conversion will
>>> fail if
>>>    * the physical address can't be internally converted to an IO
>>> token with
>>>    * pci_address_to_pio(), that is because it's either called to
>>> early or it
>>>    * can't be matched to any host bridge IO space
>>>    */
>>> int of_address_to_resource(struct device_node *dev, int index,
>>>                struct resource *r)
>>
>> The problem here seems to be that the code assumes that either the I/O
>> ports
>> are always mapped or they are never mapped (no PCI_IOBASE). We need to
>> extend
>> it because now we can have the combination of the two.
>
>
> Arnd , please take a look at the new solution when you have a
> moment,thanks.
> I modify the "drivers/of/address.c" to address the problem above.
>
> There are some assumptions:
>
> 1) ISA(LPC) Like bus must be scanned before PCI.
> 2) a property "unmapped-size" is introduced to ISA bus DT config, it
> means the address
>   range of the bus. if bus-A have a port range(0-99), bus-B have a port
> range(0-199), then
> the cpu port range (0-99) is reserved for bus-A and cpu port range (100, 299) is
> reserved for bus-B.
> 3) It it

I sorry, I made a mistake, please ignore 3). And I added the cpu port 
range(100, 299) for bus-B.

> ---
>   drivers/of/address.c | 76
> +++++++++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 9582c57..d3c71e5 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -682,8 +682,16 @@ struct io_range {
>
>   static LIST_HEAD(io_range_list);
>   static DEFINE_SPINLOCK(io_range_lock);
> +phy_addr_t pci_pio_start = 0;
> +EXPORT_SYMBOL(pci_pio_start)
>   #endif
>
> +int isa_register_unmapped_io_range(resource_size_t size)
> +{
> +       pci_pio_start += size;
> +}
> +
> +
>   /*
>    * Record the PCI IO range (expressed as CPU physical address + size).
>    * Return a negative value if an error has occured, zero otherwise
> @@ -694,7 +702,7 @@ int __weak pci_register_io_range(phys_addr_t addr,
> resource_size_t size)
>
>   #ifdef PCI_IOBASE
>          struct io_range *range;
> -       resource_size_t allocated_size = 0;
> +       resource_size_t allocated_size = pci_pio_start;
>
>          /* check if the range hasn't been previously recorded */
>          spin_lock(&io_range_lock);
> @@ -743,7 +751,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>
>   #ifdef PCI_IOBASE
>          struct io_range *range;
> -       resource_size_t allocated_size = 0;
> +       resource_size_t allocated_size = pci_pio_start;
>
>          if (pio > IO_SPACE_LIMIT)
>                  return address;
> @@ -766,7 +774,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t
> address)
>   {
>   #ifdef PCI_IOBASE
>          struct io_range *res;
> -       resource_size_t offset = 0;
> +       resource_size_t offset = pci_pio_start;
>          unsigned long addr = -1;
>
>          spin_lock(&io_range_lock);
> @@ -788,21 +796,77 @@ unsigned long __weak
> pci_address_to_pio(phys_addr_t address)
>   #endif
>   }
>
> +static u64 of_get_unmapped_pio(struct device_node *dev, const __be32
> *inaddr)
> +{
> +       struct device_node *np, *parent = NULL;
> +       struct of_bus * bus, *pbus;
> +       struct property *p_property;
> +       int rlen;
> +       u32 size = 0;
> +       u32 port_base = 0;
> +
> +       /*IF NOT I/O port*/
> +       if(*(in_addr) != 0x01)
> +               return OF_BAD_ADDR;
> +       else
> +               *in_addr = 0;
> +
> +       parent = of_get_parent(dev);
> +       if(parent == NULL)
> +               return result;
> +       bus = of_match_bus(parent);
> +       if(!strcmp(bus->name, "isa")) {
> +               p_property = of_find_property(parent, "ranges", &rlen);
> +               /*no ranges property, this is a non-bridged isa bus, and
> the port on it is unmapped*/
> +               if(p_property == NULL) {
> +                       for_each_node_by_name(np, "isa") {
> +                               if((np != parent) &&
> +                                  !of_find_property(parent, "ranges",
> &rlen) &&
> +                                  !of_property_read_u32(parent,
> "unmapped-size", &size)) {
> +                                       port_base += size;
> +                               }
> +                               else if (np == parent) {
> +                                       of_bus_default_translate(in_addr
> + 1, port_base, 1);
> +                                       break;
> +                               }
> +                               else {
> +                                       continue;
> +                               }
> +                       }
> +                       return of_read_number(in_addr, 2);
> +
> +               }
> +
> +       }
> +       return OF_BAD_ADDR;
> +}
> +
>   static int __of_address_to_resource(struct device_node *dev,
>                  const __be32 *addrp, u64 size, unsigned int flags,
>                  const char *name, struct resource *r)
>   {
>          u64 taddr;
> +       u8 addr_type = 0;
>
>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>                  return -EINVAL;
>          taddr = of_translate_address(dev, addrp);
> -       if (taddr == OF_BAD_ADDR)
> -               return -EINVAL;
> +       if (taddr == OF_BAD_ADDR) {
> +
> +               taddr == of_get_unmapped_pio(dev, addrp);
> +               if(taddr == OF_BAD_ADDR)
> +                       return -EINVAL
> +               else    /*we get unmapped I/O port successfully*/
> +                       addr_type = 1;
> +       }
> +
>          memset(r, 0, sizeof(struct resource));
>          if (flags & IORESOURCE_IO) {
>                  unsigned long port;
> -               port = pci_address_to_pio(taddr);
> +               if(!addr_type)
> +                       port = pci_address_to_pio(taddr);
> +               else
> +                       port = (unsigned long)taddr;
>                  if (port == (unsigned long)-1)
>                          return -EINVAL;
>                  r->start = port;

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/10 17:29, Rolland Chau 写道:
> On 2016/1/5 20:19, Arnd Bergmann wrote:
>> On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
>>> 在 2016/1/5 0:34, Arnd Bergmann 写道:
>>>> On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
>>>>> 在 2016/1/4 19:13, Arnd Bergmann 写道:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>> Ranges property can set empty, but this means 1:1 translation. the I/O
>>>>> port range is translated to MMIO address 0x00000001 00000000 to
>>>>> 0x00000001 00000004, it looks wrong else. I wonder if anyone get
>>>>> legacy
>>>>> I/O port resource from dts.
>>>>
>>>> As I said, nothing should really require the ranges property here,
>>>> unless
>>>> you have a valid IORESOURCE_MEM translation. The code that requires
>>>> the ranges to be present is wrong.
>>>>
>>>
>>> I think the openfirmware(DT) do not support for those unmapped I/O
>>> ports, because I
>>> must get resource by calling of_address_to_resource(), which have to
>>> call
>>> pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I
>>> have no
>>> better idea for this now. Maybe liviu can give me some opinions.
>>
>> I think on x86 it works (or used to work, few people use open firmware on
>> x86 these days, and it may be broken), and the pci_address_to_pio() call
>> behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
>> memory mapped I/O addresses, they have their own way of accessing them
>> just like your platform.
>>
>>> /**
>>>    * of_address_to_resource - Translate device tree address and
>>> return as resource
>>>    *
>>>    * Note that if your address is a PIO address, the conversion will
>>> fail if
>>>    * the physical address can't be internally converted to an IO
>>> token with
>>>    * pci_address_to_pio(), that is because it's either called to
>>> early or it
>>>    * can't be matched to any host bridge IO space
>>>    */
>>> int of_address_to_resource(struct device_node *dev, int index,
>>>                struct resource *r)
>>
>> The problem here seems to be that the code assumes that either the I/O
>> ports
>> are always mapped or they are never mapped (no PCI_IOBASE). We need to
>> extend
>> it because now we can have the combination of the two.
>
>
> Arnd , please take a look at the new solution when you have a
> moment,thanks.
> I modify the "drivers/of/address.c" to address the problem above.
>
> There are some assumptions:
>
> 1) ISA(LPC) Like bus must be scanned before PCI.
> 2) a property "unmapped-size" is introduced to ISA bus DT config, it
> means the address
>   range of the bus. if bus-A have a port range(0-99), bus-B have a port
> range(0-199), then
> the cpu port range (0-99) is reserved for bus-A and cpu port range (100, 299) is
> reserved for bus-B.
> 3) It it

I sorry, I made a mistake, please ignore 3). And I added the cpu port 
range(100, 299) for bus-B.

> ---
>   drivers/of/address.c | 76
> +++++++++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 9582c57..d3c71e5 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -682,8 +682,16 @@ struct io_range {
>
>   static LIST_HEAD(io_range_list);
>   static DEFINE_SPINLOCK(io_range_lock);
> +phy_addr_t pci_pio_start = 0;
> +EXPORT_SYMBOL(pci_pio_start)
>   #endif
>
> +int isa_register_unmapped_io_range(resource_size_t size)
> +{
> +       pci_pio_start += size;
> +}
> +
> +
>   /*
>    * Record the PCI IO range (expressed as CPU physical address + size).
>    * Return a negative value if an error has occured, zero otherwise
> @@ -694,7 +702,7 @@ int __weak pci_register_io_range(phys_addr_t addr,
> resource_size_t size)
>
>   #ifdef PCI_IOBASE
>          struct io_range *range;
> -       resource_size_t allocated_size = 0;
> +       resource_size_t allocated_size = pci_pio_start;
>
>          /* check if the range hasn't been previously recorded */
>          spin_lock(&io_range_lock);
> @@ -743,7 +751,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>
>   #ifdef PCI_IOBASE
>          struct io_range *range;
> -       resource_size_t allocated_size = 0;
> +       resource_size_t allocated_size = pci_pio_start;
>
>          if (pio > IO_SPACE_LIMIT)
>                  return address;
> @@ -766,7 +774,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t
> address)
>   {
>   #ifdef PCI_IOBASE
>          struct io_range *res;
> -       resource_size_t offset = 0;
> +       resource_size_t offset = pci_pio_start;
>          unsigned long addr = -1;
>
>          spin_lock(&io_range_lock);
> @@ -788,21 +796,77 @@ unsigned long __weak
> pci_address_to_pio(phys_addr_t address)
>   #endif
>   }
>
> +static u64 of_get_unmapped_pio(struct device_node *dev, const __be32
> *inaddr)
> +{
> +       struct device_node *np, *parent = NULL;
> +       struct of_bus * bus, *pbus;
> +       struct property *p_property;
> +       int rlen;
> +       u32 size = 0;
> +       u32 port_base = 0;
> +
> +       /*IF NOT I/O port*/
> +       if(*(in_addr) != 0x01)
> +               return OF_BAD_ADDR;
> +       else
> +               *in_addr = 0;
> +
> +       parent = of_get_parent(dev);
> +       if(parent == NULL)
> +               return result;
> +       bus = of_match_bus(parent);
> +       if(!strcmp(bus->name, "isa")) {
> +               p_property = of_find_property(parent, "ranges", &rlen);
> +               /*no ranges property, this is a non-bridged isa bus, and
> the port on it is unmapped*/
> +               if(p_property == NULL) {
> +                       for_each_node_by_name(np, "isa") {
> +                               if((np != parent) &&
> +                                  !of_find_property(parent, "ranges",
> &rlen) &&
> +                                  !of_property_read_u32(parent,
> "unmapped-size", &size)) {
> +                                       port_base += size;
> +                               }
> +                               else if (np == parent) {
> +                                       of_bus_default_translate(in_addr
> + 1, port_base, 1);
> +                                       break;
> +                               }
> +                               else {
> +                                       continue;
> +                               }
> +                       }
> +                       return of_read_number(in_addr, 2);
> +
> +               }
> +
> +       }
> +       return OF_BAD_ADDR;
> +}
> +
>   static int __of_address_to_resource(struct device_node *dev,
>                  const __be32 *addrp, u64 size, unsigned int flags,
>                  const char *name, struct resource *r)
>   {
>          u64 taddr;
> +       u8 addr_type = 0;
>
>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>                  return -EINVAL;
>          taddr = of_translate_address(dev, addrp);
> -       if (taddr == OF_BAD_ADDR)
> -               return -EINVAL;
> +       if (taddr == OF_BAD_ADDR) {
> +
> +               taddr == of_get_unmapped_pio(dev, addrp);
> +               if(taddr == OF_BAD_ADDR)
> +                       return -EINVAL
> +               else    /*we get unmapped I/O port successfully*/
> +                       addr_type = 1;
> +       }
> +
>          memset(r, 0, sizeof(struct resource));
>          if (flags & IORESOURCE_IO) {
>                  unsigned long port;
> -               port = pci_address_to_pio(taddr);
> +               if(!addr_type)
> +                       port = pci_address_to_pio(taddr);
> +               else
> +                       port = (unsigned long)taddr;
>                  if (port == (unsigned long)-1)
>                          return -EINVAL;
>                  r->start = port;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> > 在 2015/12/31 23:00, Rongrong Zou 写道:
> > > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
> > >  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> > >  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> > >  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> > >  >
> > >  > The DT sample above looks good in principle. I believe what you are missing
> > >  > here is code in your driver to scan the child nodes to create the platform
> > >  > devices. of_bus_isa_translate() should work with your definition here
> > >  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> > >  > resources, so the absence of a ranges property is ok. Maybe all you
> > >  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> > >  >
> > >
> > > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > > will be sent later. By the way, it's my another email account use when i at home.
> > 
> > I tried, and there need some additional changes.
> > 
> > isa@a01b0000 {
> > 
> > /*the node name should start with "isa", because of below definition
> > * static int of_bus_isa_match(struct device_node *np)
> > * {
> > *	return !strcmp(np->name, "isa");
> > * }
> 
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
> 
> > */
> > 	compatible = "low-pin-count";
> > 	device_type = "isa";
> > 	#address-cells = <2>;
> > 	#size-cells = <1>;
> > 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> > 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> > /*
> > *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> > *
> > */
> > 	ipmi_0:ipmi@000000e4{
> > 		device_type = "ipmi";
> > 		compatible = "ipmi-bt";
> > 		reg = <0x1 0x000000e4 0x4>;
> > };
> > 
> 
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.
> 
> > drivers\of\address.c
> > static int __of_address_to_resource(struct device_node *dev,
> >                  const __be32 *addrp, u64 size, unsigned int flags,
> >                  const char *name, struct resource *r)
> > {
> >          u64 taddr;
> > 
> >          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >                  return -EINVAL;
> >          taddr = of_translate_address(dev, addrp);
> >          if (taddr == OF_BAD_ADDR)
> >                  return -EINVAL;
> >          memset(r, 0, sizeof(struct resource));
> >          if (flags & IORESOURCE_IO) {
> >                  unsigned long port;
> > 
> > /*****************************************************************/
> > /*legacy port(< 0x1000) is reserved, and need no translation here*/
> > /*****************************************************************/
> >                  if(taddr + size < PCIBIOS_MIN_IO){
> >                          r->start = taddr;
> >                          r->end = taddr + size - 1;
> >                  }
> 
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
> 
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.

Hi,      
         
Getting back to work after a longer holiday, my brain might not be running
at full speed here, so I'm trying to clarify things a bit here.

It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
added to arm64 by patch 1/3 and redirect those operations to the memory
mapped LPC driver. I think the whole redirection and registration of inb/outb
ops can be made cleaner, so that the general concept resembles the DMA ops
registration? (I have this mental picture that what Rongrong is trying to do
is similar to what a DMA engine does, except this is slowing down things to
byte level). If that is done properly in the parent node, then we should not
care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
go through the redirection for the children.

As for the ranges property: does he wants the ipmi-bt driver to see in the
reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
then I agree that the range property should not be required, but also the
reg values need to be changed (drop the top bit). If the later, then the
ranges property is required to do the proper translation.

Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
the of_address_to_resource() translation?

Best regards,
Liviu


> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> > ? 2015/12/31 23:00, Rongrong Zou ??:
> > > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
> > >  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> > >  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
> > >  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> > >  >
> > >  > The DT sample above looks good in principle. I believe what you are missing
> > >  > here is code in your driver to scan the child nodes to create the platform
> > >  > devices. of_bus_isa_translate() should work with your definition here
> > >  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> > >  > resources, so the absence of a ranges property is ok. Maybe all you
> > >  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> > >  >
> > >
> > > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > > will be sent later. By the way, it's my another email account use when i at home.
> > 
> > I tried, and there need some additional changes.
> > 
> > isa at a01b0000 {
> > 
> > /*the node name should start with "isa", because of below definition
> > * static int of_bus_isa_match(struct device_node *np)
> > * {
> > *	return !strcmp(np->name, "isa");
> > * }
> 
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
> 
> > */
> > 	compatible = "low-pin-count";
> > 	device_type = "isa";
> > 	#address-cells = <2>;
> > 	#size-cells = <1>;
> > 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> > 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> > /*
> > *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> > *
> > */
> > 	ipmi_0:ipmi at 000000e4{
> > 		device_type = "ipmi";
> > 		compatible = "ipmi-bt";
> > 		reg = <0x1 0x000000e4 0x4>;
> > };
> > 
> 
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.
> 
> > drivers\of\address.c
> > static int __of_address_to_resource(struct device_node *dev,
> >                  const __be32 *addrp, u64 size, unsigned int flags,
> >                  const char *name, struct resource *r)
> > {
> >          u64 taddr;
> > 
> >          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >                  return -EINVAL;
> >          taddr = of_translate_address(dev, addrp);
> >          if (taddr == OF_BAD_ADDR)
> >                  return -EINVAL;
> >          memset(r, 0, sizeof(struct resource));
> >          if (flags & IORESOURCE_IO) {
> >                  unsigned long port;
> > 
> > /*****************************************************************/
> > /*legacy port(< 0x1000) is reserved, and need no translation here*/
> > /*****************************************************************/
> >                  if(taddr + size < PCIBIOS_MIN_IO){
> >                          r->start = taddr;
> >                          r->end = taddr + size - 1;
> >                  }
> 
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
> 
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.

Hi,      
         
Getting back to work after a longer holiday, my brain might not be running
at full speed here, so I'm trying to clarify things a bit here.

It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
added to arm64 by patch 1/3 and redirect those operations to the memory
mapped LPC driver. I think the whole redirection and registration of inb/outb
ops can be made cleaner, so that the general concept resembles the DMA ops
registration? (I have this mental picture that what Rongrong is trying to do
is similar to what a DMA engine does, except this is slowing down things to
byte level). If that is done properly in the parent node, then we should not
care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
go through the redirection for the children.

As for the ranges property: does he wants the ipmi-bt driver to see in the
reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
then I agree that the range property should not be required, but also the
reg values need to be changed (drop the top bit). If the later, then the
ranges property is required to do the proper translation.

Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
the of_address_to_resource() translation?

Best regards,
Liviu


> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau-5wv7dgnIgG8]

On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> > 在 2015/12/31 23:00, Rongrong Zou 写道:
> > > 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org <mailto:arnd-r2nGTMty4D4@public.gmane.org>>:
> > >  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> > >  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> > >  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> > >  >
> > >  > The DT sample above looks good in principle. I believe what you are missing
> > >  > here is code in your driver to scan the child nodes to create the platform
> > >  > devices. of_bus_isa_translate() should work with your definition here
> > >  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> > >  > resources, so the absence of a ranges property is ok. Maybe all you
> > >  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> > >  >
> > >
> > > You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> > > will be sent later. By the way, it's my another email account use when i at home.
> > 
> > I tried, and there need some additional changes.
> > 
> > isa@a01b0000 {
> > 
> > /*the node name should start with "isa", because of below definition
> > * static int of_bus_isa_match(struct device_node *np)
> > * {
> > *	return !strcmp(np->name, "isa");
> > * }
> 
> Looks good. It would be nicer to match on device_type than on name,
> but this is ancient code and it's probably best not to touch it
> so we don't accidentally break some old SPARC or PPC system.
> 
> > */
> > 	compatible = "low-pin-count";
> > 	device_type = "isa";
> > 	#address-cells = <2>;
> > 	#size-cells = <1>;
> > 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> > 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> > /*
> > *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> > *
> > */
> > 	ipmi_0:ipmi@000000e4{
> > 		device_type = "ipmi";
> > 		compatible = "ipmi-bt";
> > 		reg = <0x1 0x000000e4 0x4>;
> > };
> > 
> 
> This looks wrong: the property above says that the I/O port range is
> translated to MMIO address 0x00000000 to 0x00010000, which is not
> true on your hardware. I think this needs to be changed in the code
> so the ranges property is not required for I/O ports.
> 
> > drivers\of\address.c
> > static int __of_address_to_resource(struct device_node *dev,
> >                  const __be32 *addrp, u64 size, unsigned int flags,
> >                  const char *name, struct resource *r)
> > {
> >          u64 taddr;
> > 
> >          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >                  return -EINVAL;
> >          taddr = of_translate_address(dev, addrp);
> >          if (taddr == OF_BAD_ADDR)
> >                  return -EINVAL;
> >          memset(r, 0, sizeof(struct resource));
> >          if (flags & IORESOURCE_IO) {
> >                  unsigned long port;
> > 
> > /*****************************************************************/
> > /*legacy port(< 0x1000) is reserved, and need no translation here*/
> > /*****************************************************************/
> >                  if(taddr + size < PCIBIOS_MIN_IO){
> >                          r->start = taddr;
> >                          r->end = taddr + size - 1;
> >                  }
> 
> I don't like having a special case based on the address here,
> the same kind of hack might be needed for PCI I/O spaces in
> hardware that uses an indirect method like your LPC bus
> does, and the code above will not work on any LPC implementation
> that correctly multiplexes its I/O ports with the first PCI domain.
> 
> I think it would be better to avoid translating the port into
> a physical address to start with just to translate it back into
> a port number, what we need instead is the offset between the
> bus specific port number and the linux port number. I've added
> Liviu to Cc, he wrote this code originally and may have some idea
> of how we could do that.

Hi,      
         
Getting back to work after a longer holiday, my brain might not be running
at full speed here, so I'm trying to clarify things a bit here.

It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
added to arm64 by patch 1/3 and redirect those operations to the memory
mapped LPC driver. I think the whole redirection and registration of inb/outb
ops can be made cleaner, so that the general concept resembles the DMA ops
registration? (I have this mental picture that what Rongrong is trying to do
is similar to what a DMA engine does, except this is slowing down things to
byte level). If that is done properly in the parent node, then we should not
care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
go through the redirection for the children.

As for the ranges property: does he wants the ipmi-bt driver to see in the
reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
then I agree that the range property should not be required, but also the
reg values need to be changed (drop the top bit). If the later, then the
ranges property is required to do the proper translation.

Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
the of_address_to_resource() translation?

Best regards,
Liviu


> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>   >
>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>   >
>>>>
>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>
>>> I tried, and there need some additional changes.
>>>
>>> isa@a01b0000 {
>>>
>>> /*the node name should start with "isa", because of below definition
>>> * static int of_bus_isa_match(struct device_node *np)
>>> * {
>>> *	return !strcmp(np->name, "isa");
>>> * }
>>
>> Looks good. It would be nicer to match on device_type than on name,
>> but this is ancient code and it's probably best not to touch it
>> so we don't accidentally break some old SPARC or PPC system.
>>
>>> */
>>> 	compatible = "low-pin-count";
>>> 	device_type = "isa";
>>> 	#address-cells = <2>;
>>> 	#size-cells = <1>;
>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>> /*
>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>> *
>>> */
>>> 	ipmi_0:ipmi@000000e4{
>>> 		device_type = "ipmi";
>>> 		compatible = "ipmi-bt";
>>> 		reg = <0x1 0x000000e4 0x4>;
>>> };
>>>
>>
>> This looks wrong: the property above says that the I/O port range is
>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>> true on your hardware. I think this needs to be changed in the code
>> so the ranges property is not required for I/O ports.
>>
>>> drivers\of\address.c
>>> static int __of_address_to_resource(struct device_node *dev,
>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>                   const char *name, struct resource *r)
>>> {
>>>           u64 taddr;
>>>
>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>                   return -EINVAL;
>>>           taddr = of_translate_address(dev, addrp);
>>>           if (taddr == OF_BAD_ADDR)
>>>                   return -EINVAL;
>>>           memset(r, 0, sizeof(struct resource));
>>>           if (flags & IORESOURCE_IO) {
>>>                   unsigned long port;
>>>
>>> /*****************************************************************/
>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>> /*****************************************************************/
>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>                           r->start = taddr;
>>>                           r->end = taddr + size - 1;
>>>                   }
>>
>> I don't like having a special case based on the address here,
>> the same kind of hack might be needed for PCI I/O spaces in
>> hardware that uses an indirect method like your LPC bus
>> does, and the code above will not work on any LPC implementation
>> that correctly multiplexes its I/O ports with the first PCI domain.
>>
>> I think it would be better to avoid translating the port into
>> a physical address to start with just to translate it back into
>> a port number, what we need instead is the offset between the
>> bus specific port number and the linux port number. I've added
>> Liviu to Cc, he wrote this code originally and may have some idea
>> of how we could do that.
>
> Hi,

Hi Liviu,

Thanks for reviewing this.

>
> Getting back to work after a longer holiday, my brain might not be running
> at full speed here, so I'm trying to clarify things a bit here.
>
> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> added to arm64 by patch 1/3 and redirect those operations to the memory
> mapped LPC driver. I think the whole redirection and registration of inb/outb
> ops can be made cleaner, so that the general concept resembles the DMA ops
> registration? (I have this mental picture that what Rongrong is trying to do
> is similar to what a DMA engine does, except this is slowing down things to
> byte level). If that is done properly in the parent node, then we should not
> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> go through the redirection for the children.
>
> As for the ranges property: does he wants the ipmi-bt driver to see in the
> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> then I agree that the range property should not be required, but also the
> reg values need to be changed (drop the top bit). If the later, then the
> ranges property is required to do the proper translation.

The former, thanks.

>
> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> the of_address_to_resource() translation?

I want to get IORESOURCE_IO type resource, but if the parent node drop the
"rangs" property, the of_address_to_resource() translation will return with -EINVAL.

>
> Best regards,
> Liviu
>
>
>>
>> 	Arnd
>>
>
Regards,
Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>   > > ? 2015/12/30 17:06, Arnd Bergmann ??:
>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>   >
>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>   >
>>>>
>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>
>>> I tried, and there need some additional changes.
>>>
>>> isa at a01b0000 {
>>>
>>> /*the node name should start with "isa", because of below definition
>>> * static int of_bus_isa_match(struct device_node *np)
>>> * {
>>> *	return !strcmp(np->name, "isa");
>>> * }
>>
>> Looks good. It would be nicer to match on device_type than on name,
>> but this is ancient code and it's probably best not to touch it
>> so we don't accidentally break some old SPARC or PPC system.
>>
>>> */
>>> 	compatible = "low-pin-count";
>>> 	device_type = "isa";
>>> 	#address-cells = <2>;
>>> 	#size-cells = <1>;
>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>> /*
>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>> *
>>> */
>>> 	ipmi_0:ipmi at 000000e4{
>>> 		device_type = "ipmi";
>>> 		compatible = "ipmi-bt";
>>> 		reg = <0x1 0x000000e4 0x4>;
>>> };
>>>
>>
>> This looks wrong: the property above says that the I/O port range is
>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>> true on your hardware. I think this needs to be changed in the code
>> so the ranges property is not required for I/O ports.
>>
>>> drivers\of\address.c
>>> static int __of_address_to_resource(struct device_node *dev,
>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>                   const char *name, struct resource *r)
>>> {
>>>           u64 taddr;
>>>
>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>                   return -EINVAL;
>>>           taddr = of_translate_address(dev, addrp);
>>>           if (taddr == OF_BAD_ADDR)
>>>                   return -EINVAL;
>>>           memset(r, 0, sizeof(struct resource));
>>>           if (flags & IORESOURCE_IO) {
>>>                   unsigned long port;
>>>
>>> /*****************************************************************/
>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>> /*****************************************************************/
>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>                           r->start = taddr;
>>>                           r->end = taddr + size - 1;
>>>                   }
>>
>> I don't like having a special case based on the address here,
>> the same kind of hack might be needed for PCI I/O spaces in
>> hardware that uses an indirect method like your LPC bus
>> does, and the code above will not work on any LPC implementation
>> that correctly multiplexes its I/O ports with the first PCI domain.
>>
>> I think it would be better to avoid translating the port into
>> a physical address to start with just to translate it back into
>> a port number, what we need instead is the offset between the
>> bus specific port number and the linux port number. I've added
>> Liviu to Cc, he wrote this code originally and may have some idea
>> of how we could do that.
>
> Hi,

Hi Liviu,

Thanks for reviewing this.

>
> Getting back to work after a longer holiday, my brain might not be running
> at full speed here, so I'm trying to clarify things a bit here.
>
> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> added to arm64 by patch 1/3 and redirect those operations to the memory
> mapped LPC driver. I think the whole redirection and registration of inb/outb
> ops can be made cleaner, so that the general concept resembles the DMA ops
> registration? (I have this mental picture that what Rongrong is trying to do
> is similar to what a DMA engine does, except this is slowing down things to
> byte level). If that is done properly in the parent node, then we should not
> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> go through the redirection for the children.
>
> As for the ranges property: does he wants the ipmi-bt driver to see in the
> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> then I agree that the range property should not be required, but also the
> reg values need to be changed (drop the top bit). If the later, then the
> ranges property is required to do the proper translation.

The former, thanks.

>
> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> the of_address_to_resource() translation?

I want to get IORESOURCE_IO type resource, but if the parent node drop the
"rangs" property, the of_address_to_resource() translation will return with -EINVAL.

>
> Best regards,
> Liviu
>
>
>>
>> 	Arnd
>>
>
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
> >On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>在 2015/12/31 23:00, Rongrong Zou 写道:
> >>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
> >>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>  >
> >>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>  >
> >>>>
> >>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>
> >>>I tried, and there need some additional changes.
> >>>
> >>>isa@a01b0000 {
> >>>
> >>>/*the node name should start with "isa", because of below definition
> >>>* static int of_bus_isa_match(struct device_node *np)
> >>>* {
> >>>*	return !strcmp(np->name, "isa");
> >>>* }
> >>
> >>Looks good. It would be nicer to match on device_type than on name,
> >>but this is ancient code and it's probably best not to touch it
> >>so we don't accidentally break some old SPARC or PPC system.
> >>
> >>>*/
> >>>	compatible = "low-pin-count";
> >>>	device_type = "isa";
> >>>	#address-cells = <2>;
> >>>	#size-cells = <1>;
> >>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>/*
> >>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>*
> >>>*/
> >>>	ipmi_0:ipmi@000000e4{
> >>>		device_type = "ipmi";
> >>>		compatible = "ipmi-bt";
> >>>		reg = <0x1 0x000000e4 0x4>;
> >>>};
> >>>
> >>
> >>This looks wrong: the property above says that the I/O port range is
> >>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>true on your hardware. I think this needs to be changed in the code
> >>so the ranges property is not required for I/O ports.
> >>
> >>>drivers\of\address.c
> >>>static int __of_address_to_resource(struct device_node *dev,
> >>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>                  const char *name, struct resource *r)
> >>>{
> >>>          u64 taddr;
> >>>
> >>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>                  return -EINVAL;
> >>>          taddr = of_translate_address(dev, addrp);
> >>>          if (taddr == OF_BAD_ADDR)
> >>>                  return -EINVAL;
> >>>          memset(r, 0, sizeof(struct resource));
> >>>          if (flags & IORESOURCE_IO) {
> >>>                  unsigned long port;
> >>>
> >>>/*****************************************************************/
> >>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>/*****************************************************************/
> >>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>                          r->start = taddr;
> >>>                          r->end = taddr + size - 1;
> >>>                  }
> >>
> >>I don't like having a special case based on the address here,
> >>the same kind of hack might be needed for PCI I/O spaces in
> >>hardware that uses an indirect method like your LPC bus
> >>does, and the code above will not work on any LPC implementation
> >>that correctly multiplexes its I/O ports with the first PCI domain.
> >>
> >>I think it would be better to avoid translating the port into
> >>a physical address to start with just to translate it back into
> >>a port number, what we need instead is the offset between the
> >>bus specific port number and the linux port number. I've added
> >>Liviu to Cc, he wrote this code originally and may have some idea
> >>of how we could do that.
> >
> >Hi,
> 
> Hi Liviu,
> 
> Thanks for reviewing this.
> 
> >
> >Getting back to work after a longer holiday, my brain might not be running
> >at full speed here, so I'm trying to clarify things a bit here.
> >
> >It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >added to arm64 by patch 1/3 and redirect those operations to the memory
> >mapped LPC driver. I think the whole redirection and registration of inb/outb
> >ops can be made cleaner, so that the general concept resembles the DMA ops
> >registration? (I have this mental picture that what Rongrong is trying to do
> >is similar to what a DMA engine does, except this is slowing down things to
> >byte level). If that is done properly in the parent node, then we should not
> >care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >go through the redirection for the children.
> >
> >As for the ranges property: does he wants the ipmi-bt driver to see in the
> >reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >then I agree that the range property should not be required, but also the
> >reg values need to be changed (drop the top bit). If the later, then the
> >ranges property is required to do the proper translation.
> 
> The former, thanks.
> 
> >
> >Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >the of_address_to_resource() translation?
> 
> I want to get IORESOURCE_IO type resource, but if the parent node drop the
> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.

Have you tracked what part of the code is sensitive to the presence of "ranges"
property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?

Best regards,
Liviu

> 
> >
> >Best regards,
> >Liviu
> >
> >
> >>
> >>	Arnd
> >>
> >
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
> >On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>? 2015/12/31 23:00, Rongrong Zou ??:
> >>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
> >>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
> >>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>  >
> >>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>  >
> >>>>
> >>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>
> >>>I tried, and there need some additional changes.
> >>>
> >>>isa at a01b0000 {
> >>>
> >>>/*the node name should start with "isa", because of below definition
> >>>* static int of_bus_isa_match(struct device_node *np)
> >>>* {
> >>>*	return !strcmp(np->name, "isa");
> >>>* }
> >>
> >>Looks good. It would be nicer to match on device_type than on name,
> >>but this is ancient code and it's probably best not to touch it
> >>so we don't accidentally break some old SPARC or PPC system.
> >>
> >>>*/
> >>>	compatible = "low-pin-count";
> >>>	device_type = "isa";
> >>>	#address-cells = <2>;
> >>>	#size-cells = <1>;
> >>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>/*
> >>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>*
> >>>*/
> >>>	ipmi_0:ipmi at 000000e4{
> >>>		device_type = "ipmi";
> >>>		compatible = "ipmi-bt";
> >>>		reg = <0x1 0x000000e4 0x4>;
> >>>};
> >>>
> >>
> >>This looks wrong: the property above says that the I/O port range is
> >>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>true on your hardware. I think this needs to be changed in the code
> >>so the ranges property is not required for I/O ports.
> >>
> >>>drivers\of\address.c
> >>>static int __of_address_to_resource(struct device_node *dev,
> >>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>                  const char *name, struct resource *r)
> >>>{
> >>>          u64 taddr;
> >>>
> >>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>                  return -EINVAL;
> >>>          taddr = of_translate_address(dev, addrp);
> >>>          if (taddr == OF_BAD_ADDR)
> >>>                  return -EINVAL;
> >>>          memset(r, 0, sizeof(struct resource));
> >>>          if (flags & IORESOURCE_IO) {
> >>>                  unsigned long port;
> >>>
> >>>/*****************************************************************/
> >>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>/*****************************************************************/
> >>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>                          r->start = taddr;
> >>>                          r->end = taddr + size - 1;
> >>>                  }
> >>
> >>I don't like having a special case based on the address here,
> >>the same kind of hack might be needed for PCI I/O spaces in
> >>hardware that uses an indirect method like your LPC bus
> >>does, and the code above will not work on any LPC implementation
> >>that correctly multiplexes its I/O ports with the first PCI domain.
> >>
> >>I think it would be better to avoid translating the port into
> >>a physical address to start with just to translate it back into
> >>a port number, what we need instead is the offset between the
> >>bus specific port number and the linux port number. I've added
> >>Liviu to Cc, he wrote this code originally and may have some idea
> >>of how we could do that.
> >
> >Hi,
> 
> Hi Liviu,
> 
> Thanks for reviewing this.
> 
> >
> >Getting back to work after a longer holiday, my brain might not be running
> >at full speed here, so I'm trying to clarify things a bit here.
> >
> >It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >added to arm64 by patch 1/3 and redirect those operations to the memory
> >mapped LPC driver. I think the whole redirection and registration of inb/outb
> >ops can be made cleaner, so that the general concept resembles the DMA ops
> >registration? (I have this mental picture that what Rongrong is trying to do
> >is similar to what a DMA engine does, except this is slowing down things to
> >byte level). If that is done properly in the parent node, then we should not
> >care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >go through the redirection for the children.
> >
> >As for the ranges property: does he wants the ipmi-bt driver to see in the
> >reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >then I agree that the range property should not be required, but also the
> >reg values need to be changed (drop the top bit). If the later, then the
> >ranges property is required to do the proper translation.
> 
> The former, thanks.
> 
> >
> >Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >the of_address_to_resource() translation?
> 
> I want to get IORESOURCE_IO type resource, but if the parent node drop the
> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.

Have you tracked what part of the code is sensitive to the presence of "ranges"
property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?

Best regards,
Liviu

> 
> >
> >Best regards,
> >Liviu
> >
> >
> >>
> >>	Arnd
> >>
> >
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>   >
>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>   >
>>>>>>
>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>
>>>>> I tried, and there need some additional changes.
>>>>>
>>>>> isa@a01b0000 {
>>>>>
>>>>> /*the node name should start with "isa", because of below definition
>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>> * {
>>>>> *	return !strcmp(np->name, "isa");
>>>>> * }
>>>>
>>>> Looks good. It would be nicer to match on device_type than on name,
>>>> but this is ancient code and it's probably best not to touch it
>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>
>>>>> */
>>>>> 	compatible = "low-pin-count";
>>>>> 	device_type = "isa";
>>>>> 	#address-cells = <2>;
>>>>> 	#size-cells = <1>;
>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>> /*
>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>> *
>>>>> */
>>>>> 	ipmi_0:ipmi@000000e4{
>>>>> 		device_type = "ipmi";
>>>>> 		compatible = "ipmi-bt";
>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>> };
>>>>>
>>>>
>>>> This looks wrong: the property above says that the I/O port range is
>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>> true on your hardware. I think this needs to be changed in the code
>>>> so the ranges property is not required for I/O ports.
>>>>
>>>>> drivers\of\address.c
>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>                   const char *name, struct resource *r)
>>>>> {
>>>>>           u64 taddr;
>>>>>
>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>                   return -EINVAL;
>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>                   return -EINVAL;
>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>           if (flags & IORESOURCE_IO) {
>>>>>                   unsigned long port;
>>>>>
>>>>> /*****************************************************************/
>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>> /*****************************************************************/
>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>                           r->start = taddr;
>>>>>                           r->end = taddr + size - 1;
>>>>>                   }
>>>>
>>>> I don't like having a special case based on the address here,
>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>> hardware that uses an indirect method like your LPC bus
>>>> does, and the code above will not work on any LPC implementation
>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>
>>>> I think it would be better to avoid translating the port into
>>>> a physical address to start with just to translate it back into
>>>> a port number, what we need instead is the offset between the
>>>> bus specific port number and the linux port number. I've added
>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>> of how we could do that.
>>>
>>> Hi,
>>
>> Hi Liviu,
>>
>> Thanks for reviewing this.
>>
>>>
>>> Getting back to work after a longer holiday, my brain might not be running
>>> at full speed here, so I'm trying to clarify things a bit here.
>>>
>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>> registration? (I have this mental picture that what Rongrong is trying to do
>>> is similar to what a DMA engine does, except this is slowing down things to
>>> byte level). If that is done properly in the parent node, then we should not
>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>> go through the redirection for the children.
>>>
>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>> then I agree that the range property should not be required, but also the
>>> reg values need to be changed (drop the top bit). If the later, then the
>>> ranges property is required to do the proper translation.
>>
>> The former, thanks.
>>
>>>
>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>> the of_address_to_resource() translation?
>>
>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>
> Have you tracked what part of the code is sensitive to the presence of "ranges"
> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>


Yes, IO_RESOURCE flag can be get without "ranges".
I tracked the code, it is at of_translate_one(), Below is the calling infomation.

of_address_to_resource-> __of_address_to_resource ->of_translate_address->
__of_translate_address(dev, in_addr, "ranges")->of_translate_one()


static int of_translate_one(struct device_node *parent, struct of_bus *bus,
			    struct of_bus *pbus, __be32 *addr,
			    int na, int ns, int pna, const char *rprop)
{
	const __be32 *ranges;
	unsigned int rlen;
	int rone;
	u64 offset = OF_BAD_ADDR;

	ranges = of_get_property(parent, rprop, &rlen);
	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
		pr_debug("OF: no ranges; cannot translate\n");
		return 1;
	}
	...
}

> Best regards,
> Liviu
>
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>
>>>>
>>>> 	Arnd
>>>>
>>>
>> Regards,
>> Rongrong
>>
>
-- 
Regards,
Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/12 17:07, liviu.dudau at arm.com ??:
> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>> On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>   > > ? 2015/12/30 17:06, Arnd Bergmann ??:
>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>   >
>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>   >
>>>>>>
>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>
>>>>> I tried, and there need some additional changes.
>>>>>
>>>>> isa at a01b0000 {
>>>>>
>>>>> /*the node name should start with "isa", because of below definition
>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>> * {
>>>>> *	return !strcmp(np->name, "isa");
>>>>> * }
>>>>
>>>> Looks good. It would be nicer to match on device_type than on name,
>>>> but this is ancient code and it's probably best not to touch it
>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>
>>>>> */
>>>>> 	compatible = "low-pin-count";
>>>>> 	device_type = "isa";
>>>>> 	#address-cells = <2>;
>>>>> 	#size-cells = <1>;
>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>> /*
>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>> *
>>>>> */
>>>>> 	ipmi_0:ipmi at 000000e4{
>>>>> 		device_type = "ipmi";
>>>>> 		compatible = "ipmi-bt";
>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>> };
>>>>>
>>>>
>>>> This looks wrong: the property above says that the I/O port range is
>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>> true on your hardware. I think this needs to be changed in the code
>>>> so the ranges property is not required for I/O ports.
>>>>
>>>>> drivers\of\address.c
>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>                   const char *name, struct resource *r)
>>>>> {
>>>>>           u64 taddr;
>>>>>
>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>                   return -EINVAL;
>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>                   return -EINVAL;
>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>           if (flags & IORESOURCE_IO) {
>>>>>                   unsigned long port;
>>>>>
>>>>> /*****************************************************************/
>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>> /*****************************************************************/
>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>                           r->start = taddr;
>>>>>                           r->end = taddr + size - 1;
>>>>>                   }
>>>>
>>>> I don't like having a special case based on the address here,
>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>> hardware that uses an indirect method like your LPC bus
>>>> does, and the code above will not work on any LPC implementation
>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>
>>>> I think it would be better to avoid translating the port into
>>>> a physical address to start with just to translate it back into
>>>> a port number, what we need instead is the offset between the
>>>> bus specific port number and the linux port number. I've added
>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>> of how we could do that.
>>>
>>> Hi,
>>
>> Hi Liviu,
>>
>> Thanks for reviewing this.
>>
>>>
>>> Getting back to work after a longer holiday, my brain might not be running
>>> at full speed here, so I'm trying to clarify things a bit here.
>>>
>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>> registration? (I have this mental picture that what Rongrong is trying to do
>>> is similar to what a DMA engine does, except this is slowing down things to
>>> byte level). If that is done properly in the parent node, then we should not
>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>> go through the redirection for the children.
>>>
>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>> then I agree that the range property should not be required, but also the
>>> reg values need to be changed (drop the top bit). If the later, then the
>>> ranges property is required to do the proper translation.
>>
>> The former, thanks.
>>
>>>
>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>> the of_address_to_resource() translation?
>>
>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>
> Have you tracked what part of the code is sensitive to the presence of "ranges"
> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>


Yes, IO_RESOURCE flag can be get without "ranges".
I tracked the code, it is at of_translate_one(), Below is the calling infomation.

of_address_to_resource-> __of_address_to_resource ->of_translate_address->
__of_translate_address(dev, in_addr, "ranges")->of_translate_one()


static int of_translate_one(struct device_node *parent, struct of_bus *bus,
			    struct of_bus *pbus, __be32 *addr,
			    int na, int ns, int pna, const char *rprop)
{
	const __be32 *ranges;
	unsigned int rlen;
	int rone;
	u64 offset = OF_BAD_ADDR;

	ranges = of_get_property(parent, rprop, &rlen);
	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
		pr_debug("OF: no ranges; cannot translate\n");
		return 1;
	}
	...
}

> Best regards,
> Liviu
>
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>
>>>>
>>>> 	Arnd
>>>>
>>>
>> Regards,
>> Rongrong
>>
>
-- 
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>   >
>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>   >
>>>>>>
>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>
>>>>> I tried, and there need some additional changes.
>>>>>
>>>>> isa@a01b0000 {
>>>>>
>>>>> /*the node name should start with "isa", because of below definition
>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>> * {
>>>>> *	return !strcmp(np->name, "isa");
>>>>> * }
>>>>
>>>> Looks good. It would be nicer to match on device_type than on name,
>>>> but this is ancient code and it's probably best not to touch it
>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>
>>>>> */
>>>>> 	compatible = "low-pin-count";
>>>>> 	device_type = "isa";
>>>>> 	#address-cells = <2>;
>>>>> 	#size-cells = <1>;
>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>> /*
>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>> *
>>>>> */
>>>>> 	ipmi_0:ipmi@000000e4{
>>>>> 		device_type = "ipmi";
>>>>> 		compatible = "ipmi-bt";
>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>> };
>>>>>
>>>>
>>>> This looks wrong: the property above says that the I/O port range is
>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>> true on your hardware. I think this needs to be changed in the code
>>>> so the ranges property is not required for I/O ports.
>>>>
>>>>> drivers\of\address.c
>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>                   const char *name, struct resource *r)
>>>>> {
>>>>>           u64 taddr;
>>>>>
>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>                   return -EINVAL;
>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>                   return -EINVAL;
>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>           if (flags & IORESOURCE_IO) {
>>>>>                   unsigned long port;
>>>>>
>>>>> /*****************************************************************/
>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>> /*****************************************************************/
>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>                           r->start = taddr;
>>>>>                           r->end = taddr + size - 1;
>>>>>                   }
>>>>
>>>> I don't like having a special case based on the address here,
>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>> hardware that uses an indirect method like your LPC bus
>>>> does, and the code above will not work on any LPC implementation
>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>
>>>> I think it would be better to avoid translating the port into
>>>> a physical address to start with just to translate it back into
>>>> a port number, what we need instead is the offset between the
>>>> bus specific port number and the linux port number. I've added
>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>> of how we could do that.
>>>
>>> Hi,
>>
>> Hi Liviu,
>>
>> Thanks for reviewing this.
>>
>>>
>>> Getting back to work after a longer holiday, my brain might not be running
>>> at full speed here, so I'm trying to clarify things a bit here.
>>>
>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>> registration? (I have this mental picture that what Rongrong is trying to do
>>> is similar to what a DMA engine does, except this is slowing down things to
>>> byte level). If that is done properly in the parent node, then we should not
>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>> go through the redirection for the children.
>>>
>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>> then I agree that the range property should not be required, but also the
>>> reg values need to be changed (drop the top bit). If the later, then the
>>> ranges property is required to do the proper translation.
>>
>> The former, thanks.
>>
>>>
>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>> the of_address_to_resource() translation?
>>
>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>
> Have you tracked what part of the code is sensitive to the presence of "ranges"
> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>


Yes, IO_RESOURCE flag can be get without "ranges".
I tracked the code, it is at of_translate_one(), Below is the calling infomation.

of_address_to_resource-> __of_address_to_resource ->of_translate_address->
__of_translate_address(dev, in_addr, "ranges")->of_translate_one()


static int of_translate_one(struct device_node *parent, struct of_bus *bus,
			    struct of_bus *pbus, __be32 *addr,
			    int na, int ns, int pna, const char *rprop)
{
	const __be32 *ranges;
	unsigned int rlen;
	int rone;
	u64 offset = OF_BAD_ADDR;

	ranges = of_get_property(parent, rprop, &rlen);
	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
		pr_debug("OF: no ranges; cannot translate\n");
		return 1;
	}
	...
}

> Best regards,
> Liviu
>
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>
>>>>
>>>> 	Arnd
>>>>
>>>
>> Regards,
>> Rongrong
>>
>
-- 
Regards,
Rongrong

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> 在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
> >On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
> >>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>在 2015/12/31 23:00, Rongrong Zou 写道:
> >>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
> >>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>  >
> >>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>  >
> >>>>>>
> >>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>
> >>>>>I tried, and there need some additional changes.
> >>>>>
> >>>>>isa@a01b0000 {
> >>>>>
> >>>>>/*the node name should start with "isa", because of below definition
> >>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>* {
> >>>>>*	return !strcmp(np->name, "isa");
> >>>>>* }
> >>>>
> >>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>but this is ancient code and it's probably best not to touch it
> >>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>
> >>>>>*/
> >>>>>	compatible = "low-pin-count";
> >>>>>	device_type = "isa";
> >>>>>	#address-cells = <2>;
> >>>>>	#size-cells = <1>;
> >>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>/*
> >>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>*
> >>>>>*/
> >>>>>	ipmi_0:ipmi@000000e4{
> >>>>>		device_type = "ipmi";
> >>>>>		compatible = "ipmi-bt";
> >>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>};
> >>>>>
> >>>>
> >>>>This looks wrong: the property above says that the I/O port range is
> >>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>true on your hardware. I think this needs to be changed in the code
> >>>>so the ranges property is not required for I/O ports.
> >>>>
> >>>>>drivers\of\address.c
> >>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>                  const char *name, struct resource *r)
> >>>>>{
> >>>>>          u64 taddr;
> >>>>>
> >>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>                  return -EINVAL;
> >>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>                  return -EINVAL;
> >>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>          if (flags & IORESOURCE_IO) {
> >>>>>                  unsigned long port;
> >>>>>
> >>>>>/*****************************************************************/
> >>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>/*****************************************************************/
> >>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>                          r->start = taddr;
> >>>>>                          r->end = taddr + size - 1;
> >>>>>                  }
> >>>>
> >>>>I don't like having a special case based on the address here,
> >>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>hardware that uses an indirect method like your LPC bus
> >>>>does, and the code above will not work on any LPC implementation
> >>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>
> >>>>I think it would be better to avoid translating the port into
> >>>>a physical address to start with just to translate it back into
> >>>>a port number, what we need instead is the offset between the
> >>>>bus specific port number and the linux port number. I've added
> >>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>of how we could do that.
> >>>
> >>>Hi,
> >>
> >>Hi Liviu,
> >>
> >>Thanks for reviewing this.
> >>
> >>>
> >>>Getting back to work after a longer holiday, my brain might not be running
> >>>at full speed here, so I'm trying to clarify things a bit here.
> >>>
> >>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>is similar to what a DMA engine does, except this is slowing down things to
> >>>byte level). If that is done properly in the parent node, then we should not
> >>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>go through the redirection for the children.
> >>>
> >>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>then I agree that the range property should not be required, but also the
> >>>reg values need to be changed (drop the top bit). If the later, then the
> >>>ranges property is required to do the proper translation.
> >>
> >>The former, thanks.
> >>
> >>>
> >>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>the of_address_to_resource() translation?
> >>
> >>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >
> >Have you tracked what part of the code is sensitive to the presence of "ranges"
> >property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >
> 
> 
> Yes, IO_RESOURCE flag can be get without "ranges".
> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> 
> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> 
> 
> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> 			    struct of_bus *pbus, __be32 *addr,
> 			    int na, int ns, int pna, const char *rprop)
> {
> 	const __be32 *ranges;
> 	unsigned int rlen;
> 	int rone;
> 	u64 offset = OF_BAD_ADDR;
> 
> 	ranges = of_get_property(parent, rprop, &rlen);
> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> 		pr_debug("OF: no ranges; cannot translate\n");
> 		return 1;
> 	}
> 	...
> }

OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;

Best regards,
Liviu

> 
> >Best regards,
> >Liviu
> >
> >>
> >>>
> >>>Best regards,
> >>>Liviu
> >>>
> >>>
> >>>>
> >>>>	Arnd
> >>>>
> >>>
> >>Regards,
> >>Rongrong
> >>
> >
> -- 
> Regards,
> Rongrong
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> ? 2016/1/12 17:07, liviu.dudau at arm.com ??:
> >On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
> >>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>? 2015/12/31 23:00, Rongrong Zou ??:
> >>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
> >>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
> >>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>  >
> >>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>  >
> >>>>>>
> >>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>
> >>>>>I tried, and there need some additional changes.
> >>>>>
> >>>>>isa at a01b0000 {
> >>>>>
> >>>>>/*the node name should start with "isa", because of below definition
> >>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>* {
> >>>>>*	return !strcmp(np->name, "isa");
> >>>>>* }
> >>>>
> >>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>but this is ancient code and it's probably best not to touch it
> >>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>
> >>>>>*/
> >>>>>	compatible = "low-pin-count";
> >>>>>	device_type = "isa";
> >>>>>	#address-cells = <2>;
> >>>>>	#size-cells = <1>;
> >>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>/*
> >>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>*
> >>>>>*/
> >>>>>	ipmi_0:ipmi at 000000e4{
> >>>>>		device_type = "ipmi";
> >>>>>		compatible = "ipmi-bt";
> >>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>};
> >>>>>
> >>>>
> >>>>This looks wrong: the property above says that the I/O port range is
> >>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>true on your hardware. I think this needs to be changed in the code
> >>>>so the ranges property is not required for I/O ports.
> >>>>
> >>>>>drivers\of\address.c
> >>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>                  const char *name, struct resource *r)
> >>>>>{
> >>>>>          u64 taddr;
> >>>>>
> >>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>                  return -EINVAL;
> >>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>                  return -EINVAL;
> >>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>          if (flags & IORESOURCE_IO) {
> >>>>>                  unsigned long port;
> >>>>>
> >>>>>/*****************************************************************/
> >>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>/*****************************************************************/
> >>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>                          r->start = taddr;
> >>>>>                          r->end = taddr + size - 1;
> >>>>>                  }
> >>>>
> >>>>I don't like having a special case based on the address here,
> >>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>hardware that uses an indirect method like your LPC bus
> >>>>does, and the code above will not work on any LPC implementation
> >>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>
> >>>>I think it would be better to avoid translating the port into
> >>>>a physical address to start with just to translate it back into
> >>>>a port number, what we need instead is the offset between the
> >>>>bus specific port number and the linux port number. I've added
> >>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>of how we could do that.
> >>>
> >>>Hi,
> >>
> >>Hi Liviu,
> >>
> >>Thanks for reviewing this.
> >>
> >>>
> >>>Getting back to work after a longer holiday, my brain might not be running
> >>>at full speed here, so I'm trying to clarify things a bit here.
> >>>
> >>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>is similar to what a DMA engine does, except this is slowing down things to
> >>>byte level). If that is done properly in the parent node, then we should not
> >>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>go through the redirection for the children.
> >>>
> >>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>then I agree that the range property should not be required, but also the
> >>>reg values need to be changed (drop the top bit). If the later, then the
> >>>ranges property is required to do the proper translation.
> >>
> >>The former, thanks.
> >>
> >>>
> >>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>the of_address_to_resource() translation?
> >>
> >>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >
> >Have you tracked what part of the code is sensitive to the presence of "ranges"
> >property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >
> 
> 
> Yes, IO_RESOURCE flag can be get without "ranges".
> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> 
> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> 
> 
> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> 			    struct of_bus *pbus, __be32 *addr,
> 			    int na, int ns, int pna, const char *rprop)
> {
> 	const __be32 *ranges;
> 	unsigned int rlen;
> 	int rone;
> 	u64 offset = OF_BAD_ADDR;
> 
> 	ranges = of_get_property(parent, rprop, &rlen);
> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> 		pr_debug("OF: no ranges; cannot translate\n");
> 		return 1;
> 	}
> 	...
> }

OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;

Best regards,
Liviu

> 
> >Best regards,
> >Liviu
> >
> >>
> >>>
> >>>Best regards,
> >>>Liviu
> >>>
> >>>
> >>>>
> >>>>	Arnd
> >>>>
> >>>
> >>Regards,
> >>Rongrong
> >>
> >
> -- 
> Regards,
> Rongrong
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/12 18:14, liviu.dudau@arm.com 写道:
> On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
>> 在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
>>> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>>>> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
>>>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>>>   >
>>>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>>>   >
>>>>>>>>
>>>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>>>
>>>>>>> I tried, and there need some additional changes.
>>>>>>>
>>>>>>> isa@a01b0000 {
>>>>>>>
>>>>>>> /*the node name should start with "isa", because of below definition
>>>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>>>> * {
>>>>>>> *	return !strcmp(np->name, "isa");
>>>>>>> * }
>>>>>>
>>>>>> Looks good. It would be nicer to match on device_type than on name,
>>>>>> but this is ancient code and it's probably best not to touch it
>>>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>>>
>>>>>>> */
>>>>>>> 	compatible = "low-pin-count";
>>>>>>> 	device_type = "isa";
>>>>>>> 	#address-cells = <2>;
>>>>>>> 	#size-cells = <1>;
>>>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>>>> /*
>>>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>>>> *
>>>>>>> */
>>>>>>> 	ipmi_0:ipmi@000000e4{
>>>>>>> 		device_type = "ipmi";
>>>>>>> 		compatible = "ipmi-bt";
>>>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> This looks wrong: the property above says that the I/O port range is
>>>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>>>> true on your hardware. I think this needs to be changed in the code
>>>>>> so the ranges property is not required for I/O ports.
>>>>>>
>>>>>>> drivers\of\address.c
>>>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>>>                   const char *name, struct resource *r)
>>>>>>> {
>>>>>>>           u64 taddr;
>>>>>>>
>>>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>>>                   return -EINVAL;
>>>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>>>                   return -EINVAL;
>>>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>>>           if (flags & IORESOURCE_IO) {
>>>>>>>                   unsigned long port;
>>>>>>>
>>>>>>> /*****************************************************************/
>>>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>>>> /*****************************************************************/
>>>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>>>                           r->start = taddr;
>>>>>>>                           r->end = taddr + size - 1;
>>>>>>>                   }
>>>>>>
>>>>>> I don't like having a special case based on the address here,
>>>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>>>> hardware that uses an indirect method like your LPC bus
>>>>>> does, and the code above will not work on any LPC implementation
>>>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>>>
>>>>>> I think it would be better to avoid translating the port into
>>>>>> a physical address to start with just to translate it back into
>>>>>> a port number, what we need instead is the offset between the
>>>>>> bus specific port number and the linux port number. I've added
>>>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>>>> of how we could do that.
>>>>>
>>>>> Hi,
>>>>
>>>> Hi Liviu,
>>>>
>>>> Thanks for reviewing this.
>>>>
>>>>>
>>>>> Getting back to work after a longer holiday, my brain might not be running
>>>>> at full speed here, so I'm trying to clarify things a bit here.
>>>>>
>>>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>>>> registration? (I have this mental picture that what Rongrong is trying to do
>>>>> is similar to what a DMA engine does, except this is slowing down things to
>>>>> byte level). If that is done properly in the parent node, then we should not
>>>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>>>> go through the redirection for the children.
>>>>>
>>>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>>>> then I agree that the range property should not be required, but also the
>>>>> reg values need to be changed (drop the top bit). If the later, then the
>>>>> ranges property is required to do the proper translation.
>>>>
>>>> The former, thanks.
>>>>
>>>>>
>>>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>>>> the of_address_to_resource() translation?
>>>>
>>>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>>>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>>>
>>> Have you tracked what part of the code is sensitive to the presence of "ranges"
>>> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>>>
>>
>>
>> Yes, IO_RESOURCE flag can be get without "ranges".
>> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
>>
>> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
>> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
>>
>>
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> 			    struct of_bus *pbus, __be32 *addr,
>> 			    int na, int ns, int pna, const char *rprop)
>> {
>> 	const __be32 *ranges;
>> 	unsigned int rlen;
>> 	int rone;
>> 	u64 offset = OF_BAD_ADDR;
>>
>> 	ranges = of_get_property(parent, rprop, &rlen);
>> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
>> 		pr_debug("OF: no ranges; cannot translate\n");
>> 		return 1;
>> 	}
>> 	...
>> }
>
> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;

But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
ranges has been discussed.


>
> Best regards,
> Liviu
>
>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> Best regards,
>>>>> Liviu
>>>>>
>>>>>
>>>>>>
>>>>>> 	Arnd
>>>>>>
>>>>>
>>>> Regards,
>>>> Rongrong
>>>>
>>>
>> --
>> Regards,
>> Rongrong
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


-- 
Regards,
Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/12 18:14, liviu.dudau at arm.com ??:
> On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
>> ? 2016/1/12 17:07, liviu.dudau at arm.com ??:
>>> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>>>> On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
>>>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
>>>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>>>   > > ? 2015/12/30 17:06, Arnd Bergmann ??:
>>>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>>>   >
>>>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>>>   >
>>>>>>>>
>>>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>>>
>>>>>>> I tried, and there need some additional changes.
>>>>>>>
>>>>>>> isa at a01b0000 {
>>>>>>>
>>>>>>> /*the node name should start with "isa", because of below definition
>>>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>>>> * {
>>>>>>> *	return !strcmp(np->name, "isa");
>>>>>>> * }
>>>>>>
>>>>>> Looks good. It would be nicer to match on device_type than on name,
>>>>>> but this is ancient code and it's probably best not to touch it
>>>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>>>
>>>>>>> */
>>>>>>> 	compatible = "low-pin-count";
>>>>>>> 	device_type = "isa";
>>>>>>> 	#address-cells = <2>;
>>>>>>> 	#size-cells = <1>;
>>>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>>>> /*
>>>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>>>> *
>>>>>>> */
>>>>>>> 	ipmi_0:ipmi at 000000e4{
>>>>>>> 		device_type = "ipmi";
>>>>>>> 		compatible = "ipmi-bt";
>>>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> This looks wrong: the property above says that the I/O port range is
>>>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>>>> true on your hardware. I think this needs to be changed in the code
>>>>>> so the ranges property is not required for I/O ports.
>>>>>>
>>>>>>> drivers\of\address.c
>>>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>>>                   const char *name, struct resource *r)
>>>>>>> {
>>>>>>>           u64 taddr;
>>>>>>>
>>>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>>>                   return -EINVAL;
>>>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>>>                   return -EINVAL;
>>>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>>>           if (flags & IORESOURCE_IO) {
>>>>>>>                   unsigned long port;
>>>>>>>
>>>>>>> /*****************************************************************/
>>>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>>>> /*****************************************************************/
>>>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>>>                           r->start = taddr;
>>>>>>>                           r->end = taddr + size - 1;
>>>>>>>                   }
>>>>>>
>>>>>> I don't like having a special case based on the address here,
>>>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>>>> hardware that uses an indirect method like your LPC bus
>>>>>> does, and the code above will not work on any LPC implementation
>>>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>>>
>>>>>> I think it would be better to avoid translating the port into
>>>>>> a physical address to start with just to translate it back into
>>>>>> a port number, what we need instead is the offset between the
>>>>>> bus specific port number and the linux port number. I've added
>>>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>>>> of how we could do that.
>>>>>
>>>>> Hi,
>>>>
>>>> Hi Liviu,
>>>>
>>>> Thanks for reviewing this.
>>>>
>>>>>
>>>>> Getting back to work after a longer holiday, my brain might not be running
>>>>> at full speed here, so I'm trying to clarify things a bit here.
>>>>>
>>>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>>>> registration? (I have this mental picture that what Rongrong is trying to do
>>>>> is similar to what a DMA engine does, except this is slowing down things to
>>>>> byte level). If that is done properly in the parent node, then we should not
>>>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>>>> go through the redirection for the children.
>>>>>
>>>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>>>> then I agree that the range property should not be required, but also the
>>>>> reg values need to be changed (drop the top bit). If the later, then the
>>>>> ranges property is required to do the proper translation.
>>>>
>>>> The former, thanks.
>>>>
>>>>>
>>>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>>>> the of_address_to_resource() translation?
>>>>
>>>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>>>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>>>
>>> Have you tracked what part of the code is sensitive to the presence of "ranges"
>>> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>>>
>>
>>
>> Yes, IO_RESOURCE flag can be get without "ranges".
>> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
>>
>> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
>> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
>>
>>
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> 			    struct of_bus *pbus, __be32 *addr,
>> 			    int na, int ns, int pna, const char *rprop)
>> {
>> 	const __be32 *ranges;
>> 	unsigned int rlen;
>> 	int rone;
>> 	u64 offset = OF_BAD_ADDR;
>>
>> 	ranges = of_get_property(parent, rprop, &rlen);
>> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
>> 		pr_debug("OF: no ranges; cannot translate\n");
>> 		return 1;
>> 	}
>> 	...
>> }
>
> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;

But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
ranges has been discussed.


>
> Best regards,
> Liviu
>
>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> Best regards,
>>>>> Liviu
>>>>>
>>>>>
>>>>>>
>>>>>> 	Arnd
>>>>>>
>>>>>
>>>> Regards,
>>>> Rongrong
>>>>
>>>
>> --
>> Regards,
>> Rongrong
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


-- 
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/12 18:14, liviu.dudau@arm.com 写道:
> On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
>> 在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
>>> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>>>> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
>>>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>>>   >
>>>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>>>   >
>>>>>>>>
>>>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>>>
>>>>>>> I tried, and there need some additional changes.
>>>>>>>
>>>>>>> isa@a01b0000 {
>>>>>>>
>>>>>>> /*the node name should start with "isa", because of below definition
>>>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>>>> * {
>>>>>>> *	return !strcmp(np->name, "isa");
>>>>>>> * }
>>>>>>
>>>>>> Looks good. It would be nicer to match on device_type than on name,
>>>>>> but this is ancient code and it's probably best not to touch it
>>>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>>>
>>>>>>> */
>>>>>>> 	compatible = "low-pin-count";
>>>>>>> 	device_type = "isa";
>>>>>>> 	#address-cells = <2>;
>>>>>>> 	#size-cells = <1>;
>>>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>>>> /*
>>>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>>>> *
>>>>>>> */
>>>>>>> 	ipmi_0:ipmi@000000e4{
>>>>>>> 		device_type = "ipmi";
>>>>>>> 		compatible = "ipmi-bt";
>>>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> This looks wrong: the property above says that the I/O port range is
>>>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>>>> true on your hardware. I think this needs to be changed in the code
>>>>>> so the ranges property is not required for I/O ports.
>>>>>>
>>>>>>> drivers\of\address.c
>>>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>>>                   const char *name, struct resource *r)
>>>>>>> {
>>>>>>>           u64 taddr;
>>>>>>>
>>>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>>>                   return -EINVAL;
>>>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>>>                   return -EINVAL;
>>>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>>>           if (flags & IORESOURCE_IO) {
>>>>>>>                   unsigned long port;
>>>>>>>
>>>>>>> /*****************************************************************/
>>>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>>>> /*****************************************************************/
>>>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>>>                           r->start = taddr;
>>>>>>>                           r->end = taddr + size - 1;
>>>>>>>                   }
>>>>>>
>>>>>> I don't like having a special case based on the address here,
>>>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>>>> hardware that uses an indirect method like your LPC bus
>>>>>> does, and the code above will not work on any LPC implementation
>>>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>>>
>>>>>> I think it would be better to avoid translating the port into
>>>>>> a physical address to start with just to translate it back into
>>>>>> a port number, what we need instead is the offset between the
>>>>>> bus specific port number and the linux port number. I've added
>>>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>>>> of how we could do that.
>>>>>
>>>>> Hi,
>>>>
>>>> Hi Liviu,
>>>>
>>>> Thanks for reviewing this.
>>>>
>>>>>
>>>>> Getting back to work after a longer holiday, my brain might not be running
>>>>> at full speed here, so I'm trying to clarify things a bit here.
>>>>>
>>>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>>>> registration? (I have this mental picture that what Rongrong is trying to do
>>>>> is similar to what a DMA engine does, except this is slowing down things to
>>>>> byte level). If that is done properly in the parent node, then we should not
>>>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>>>> go through the redirection for the children.
>>>>>
>>>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>>>> then I agree that the range property should not be required, but also the
>>>>> reg values need to be changed (drop the top bit). If the later, then the
>>>>> ranges property is required to do the proper translation.
>>>>
>>>> The former, thanks.
>>>>
>>>>>
>>>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>>>> the of_address_to_resource() translation?
>>>>
>>>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>>>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>>>
>>> Have you tracked what part of the code is sensitive to the presence of "ranges"
>>> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>>>
>>
>>
>> Yes, IO_RESOURCE flag can be get without "ranges".
>> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
>>
>> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
>> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
>>
>>
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> 			    struct of_bus *pbus, __be32 *addr,
>> 			    int na, int ns, int pna, const char *rprop)
>> {
>> 	const __be32 *ranges;
>> 	unsigned int rlen;
>> 	int rone;
>> 	u64 offset = OF_BAD_ADDR;
>>
>> 	ranges = of_get_property(parent, rprop, &rlen);
>> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
>> 		pr_debug("OF: no ranges; cannot translate\n");
>> 		return 1;
>> 	}
>> 	...
>> }
>
> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;

But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
ranges has been discussed.


>
> Best regards,
> Liviu
>
>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> Best regards,
>>>>> Liviu
>>>>>
>>>>>
>>>>>>
>>>>>> 	Arnd
>>>>>>
>>>>>
>>>> Regards,
>>>> Rongrong
>>>>
>>>
>> --
>> Regards,
>> Rongrong
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


-- 
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
> 在 2016/1/12 18:14, liviu.dudau@arm.com 写道:
> >On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> >>在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
> >>>On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>>>On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
> >>>>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>>>在 2015/12/31 23:00, Rongrong Zou 写道:
> >>>>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
> >>>>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>>>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >>>>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>>>  >
> >>>>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>>>  >
> >>>>>>>>
> >>>>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>>>
> >>>>>>>I tried, and there need some additional changes.
> >>>>>>>
> >>>>>>>isa@a01b0000 {
> >>>>>>>
> >>>>>>>/*the node name should start with "isa", because of below definition
> >>>>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>>>* {
> >>>>>>>*	return !strcmp(np->name, "isa");
> >>>>>>>* }
> >>>>>>
> >>>>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>>>but this is ancient code and it's probably best not to touch it
> >>>>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>>>
> >>>>>>>*/
> >>>>>>>	compatible = "low-pin-count";
> >>>>>>>	device_type = "isa";
> >>>>>>>	#address-cells = <2>;
> >>>>>>>	#size-cells = <1>;
> >>>>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>>>/*
> >>>>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>>>*
> >>>>>>>*/
> >>>>>>>	ipmi_0:ipmi@000000e4{
> >>>>>>>		device_type = "ipmi";
> >>>>>>>		compatible = "ipmi-bt";
> >>>>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>>>};
> >>>>>>>
> >>>>>>
> >>>>>>This looks wrong: the property above says that the I/O port range is
> >>>>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>>>true on your hardware. I think this needs to be changed in the code
> >>>>>>so the ranges property is not required for I/O ports.
> >>>>>>
> >>>>>>>drivers\of\address.c
> >>>>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>>>                  const char *name, struct resource *r)
> >>>>>>>{
> >>>>>>>          u64 taddr;
> >>>>>>>
> >>>>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>>>                  return -EINVAL;
> >>>>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>>>                  return -EINVAL;
> >>>>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>>>          if (flags & IORESOURCE_IO) {
> >>>>>>>                  unsigned long port;
> >>>>>>>
> >>>>>>>/*****************************************************************/
> >>>>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>>>/*****************************************************************/
> >>>>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>>>                          r->start = taddr;
> >>>>>>>                          r->end = taddr + size - 1;
> >>>>>>>                  }
> >>>>>>
> >>>>>>I don't like having a special case based on the address here,
> >>>>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>>>hardware that uses an indirect method like your LPC bus
> >>>>>>does, and the code above will not work on any LPC implementation
> >>>>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>>>
> >>>>>>I think it would be better to avoid translating the port into
> >>>>>>a physical address to start with just to translate it back into
> >>>>>>a port number, what we need instead is the offset between the
> >>>>>>bus specific port number and the linux port number. I've added
> >>>>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>>>of how we could do that.
> >>>>>
> >>>>>Hi,
> >>>>
> >>>>Hi Liviu,
> >>>>
> >>>>Thanks for reviewing this.
> >>>>
> >>>>>
> >>>>>Getting back to work after a longer holiday, my brain might not be running
> >>>>>at full speed here, so I'm trying to clarify things a bit here.
> >>>>>
> >>>>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>>>is similar to what a DMA engine does, except this is slowing down things to
> >>>>>byte level). If that is done properly in the parent node, then we should not
> >>>>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>>>go through the redirection for the children.
> >>>>>
> >>>>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>>>then I agree that the range property should not be required, but also the
> >>>>>reg values need to be changed (drop the top bit). If the later, then the
> >>>>>ranges property is required to do the proper translation.
> >>>>
> >>>>The former, thanks.
> >>>>
> >>>>>
> >>>>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>>>the of_address_to_resource() translation?
> >>>>
> >>>>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>>>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >>>
> >>>Have you tracked what part of the code is sensitive to the presence of "ranges"
> >>>property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >>>
> >>
> >>
> >>Yes, IO_RESOURCE flag can be get without "ranges".

Earlier, you said this ^

> >>I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> >>
> >>of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> >>__of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> >>
> >>
> >>static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> >>			    struct of_bus *pbus, __be32 *addr,
> >>			    int na, int ns, int pna, const char *rprop)
> >>{
> >>	const __be32 *ranges;
> >>	unsigned int rlen;
> >>	int rone;
> >>	u64 offset = OF_BAD_ADDR;
> >>
> >>	ranges = of_get_property(parent, rprop, &rlen);
> >>	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> >>		pr_debug("OF: no ranges; cannot translate\n");
> >>		return 1;
> >>	}
> >>	...
> >>}
> >
> >OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> 
> But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
> the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
> ranges has been discussed.

So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
do you actually get, MMIO is not a valid value.

Liviu

> 
> -- 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
> ? 2016/1/12 18:14, liviu.dudau at arm.com ??:
> >On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> >>? 2016/1/12 17:07, liviu.dudau at arm.com ??:
> >>>On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>>>On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
> >>>>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>>>? 2015/12/31 23:00, Rongrong Zou ??:
> >>>>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
> >>>>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>>>  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
> >>>>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>>>  >
> >>>>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>>>  >
> >>>>>>>>
> >>>>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>>>
> >>>>>>>I tried, and there need some additional changes.
> >>>>>>>
> >>>>>>>isa at a01b0000 {
> >>>>>>>
> >>>>>>>/*the node name should start with "isa", because of below definition
> >>>>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>>>* {
> >>>>>>>*	return !strcmp(np->name, "isa");
> >>>>>>>* }
> >>>>>>
> >>>>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>>>but this is ancient code and it's probably best not to touch it
> >>>>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>>>
> >>>>>>>*/
> >>>>>>>	compatible = "low-pin-count";
> >>>>>>>	device_type = "isa";
> >>>>>>>	#address-cells = <2>;
> >>>>>>>	#size-cells = <1>;
> >>>>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>>>/*
> >>>>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>>>*
> >>>>>>>*/
> >>>>>>>	ipmi_0:ipmi at 000000e4{
> >>>>>>>		device_type = "ipmi";
> >>>>>>>		compatible = "ipmi-bt";
> >>>>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>>>};
> >>>>>>>
> >>>>>>
> >>>>>>This looks wrong: the property above says that the I/O port range is
> >>>>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>>>true on your hardware. I think this needs to be changed in the code
> >>>>>>so the ranges property is not required for I/O ports.
> >>>>>>
> >>>>>>>drivers\of\address.c
> >>>>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>>>                  const char *name, struct resource *r)
> >>>>>>>{
> >>>>>>>          u64 taddr;
> >>>>>>>
> >>>>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>>>                  return -EINVAL;
> >>>>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>>>                  return -EINVAL;
> >>>>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>>>          if (flags & IORESOURCE_IO) {
> >>>>>>>                  unsigned long port;
> >>>>>>>
> >>>>>>>/*****************************************************************/
> >>>>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>>>/*****************************************************************/
> >>>>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>>>                          r->start = taddr;
> >>>>>>>                          r->end = taddr + size - 1;
> >>>>>>>                  }
> >>>>>>
> >>>>>>I don't like having a special case based on the address here,
> >>>>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>>>hardware that uses an indirect method like your LPC bus
> >>>>>>does, and the code above will not work on any LPC implementation
> >>>>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>>>
> >>>>>>I think it would be better to avoid translating the port into
> >>>>>>a physical address to start with just to translate it back into
> >>>>>>a port number, what we need instead is the offset between the
> >>>>>>bus specific port number and the linux port number. I've added
> >>>>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>>>of how we could do that.
> >>>>>
> >>>>>Hi,
> >>>>
> >>>>Hi Liviu,
> >>>>
> >>>>Thanks for reviewing this.
> >>>>
> >>>>>
> >>>>>Getting back to work after a longer holiday, my brain might not be running
> >>>>>at full speed here, so I'm trying to clarify things a bit here.
> >>>>>
> >>>>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>>>is similar to what a DMA engine does, except this is slowing down things to
> >>>>>byte level). If that is done properly in the parent node, then we should not
> >>>>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>>>go through the redirection for the children.
> >>>>>
> >>>>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>>>then I agree that the range property should not be required, but also the
> >>>>>reg values need to be changed (drop the top bit). If the later, then the
> >>>>>ranges property is required to do the proper translation.
> >>>>
> >>>>The former, thanks.
> >>>>
> >>>>>
> >>>>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>>>the of_address_to_resource() translation?
> >>>>
> >>>>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>>>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >>>
> >>>Have you tracked what part of the code is sensitive to the presence of "ranges"
> >>>property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >>>
> >>
> >>
> >>Yes, IO_RESOURCE flag can be get without "ranges".

Earlier, you said this ^

> >>I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> >>
> >>of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> >>__of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> >>
> >>
> >>static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> >>			    struct of_bus *pbus, __be32 *addr,
> >>			    int na, int ns, int pna, const char *rprop)
> >>{
> >>	const __be32 *ranges;
> >>	unsigned int rlen;
> >>	int rone;
> >>	u64 offset = OF_BAD_ADDR;
> >>
> >>	ranges = of_get_property(parent, rprop, &rlen);
> >>	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> >>		pr_debug("OF: no ranges; cannot translate\n");
> >>		return 1;
> >>	}
> >>	...
> >>}
> >
> >OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> 
> But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
> the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
> ranges has been discussed.

So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
do you actually get, MMIO is not a valid value.

Liviu

> 
> -- 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau-5wv7dgnIgG8]

On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
> 在 2016/1/12 18:14, liviu.dudau-5wv7dgnIgG8@public.gmane.org 写道:
> >On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> >>在 2016/1/12 17:07, liviu.dudau-5wv7dgnIgG8@public.gmane.org 写道:
> >>>On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>>>On 2016/1/12 0:14, liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> >>>>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>>>在 2015/12/31 23:00, Rongrong Zou 写道:
> >>>>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org <mailto:arnd-r2nGTMty4D4@public.gmane.org>>:
> >>>>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>>>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >>>>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>>>  >
> >>>>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>>>  >
> >>>>>>>>
> >>>>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>>>
> >>>>>>>I tried, and there need some additional changes.
> >>>>>>>
> >>>>>>>isa@a01b0000 {
> >>>>>>>
> >>>>>>>/*the node name should start with "isa", because of below definition
> >>>>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>>>* {
> >>>>>>>*	return !strcmp(np->name, "isa");
> >>>>>>>* }
> >>>>>>
> >>>>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>>>but this is ancient code and it's probably best not to touch it
> >>>>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>>>
> >>>>>>>*/
> >>>>>>>	compatible = "low-pin-count";
> >>>>>>>	device_type = "isa";
> >>>>>>>	#address-cells = <2>;
> >>>>>>>	#size-cells = <1>;
> >>>>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>>>/*
> >>>>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>>>*
> >>>>>>>*/
> >>>>>>>	ipmi_0:ipmi@000000e4{
> >>>>>>>		device_type = "ipmi";
> >>>>>>>		compatible = "ipmi-bt";
> >>>>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>>>};
> >>>>>>>
> >>>>>>
> >>>>>>This looks wrong: the property above says that the I/O port range is
> >>>>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>>>true on your hardware. I think this needs to be changed in the code
> >>>>>>so the ranges property is not required for I/O ports.
> >>>>>>
> >>>>>>>drivers\of\address.c
> >>>>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>>>                  const char *name, struct resource *r)
> >>>>>>>{
> >>>>>>>          u64 taddr;
> >>>>>>>
> >>>>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>>>                  return -EINVAL;
> >>>>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>>>                  return -EINVAL;
> >>>>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>>>          if (flags & IORESOURCE_IO) {
> >>>>>>>                  unsigned long port;
> >>>>>>>
> >>>>>>>/*****************************************************************/
> >>>>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>>>/*****************************************************************/
> >>>>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>>>                          r->start = taddr;
> >>>>>>>                          r->end = taddr + size - 1;
> >>>>>>>                  }
> >>>>>>
> >>>>>>I don't like having a special case based on the address here,
> >>>>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>>>hardware that uses an indirect method like your LPC bus
> >>>>>>does, and the code above will not work on any LPC implementation
> >>>>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>>>
> >>>>>>I think it would be better to avoid translating the port into
> >>>>>>a physical address to start with just to translate it back into
> >>>>>>a port number, what we need instead is the offset between the
> >>>>>>bus specific port number and the linux port number. I've added
> >>>>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>>>of how we could do that.
> >>>>>
> >>>>>Hi,
> >>>>
> >>>>Hi Liviu,
> >>>>
> >>>>Thanks for reviewing this.
> >>>>
> >>>>>
> >>>>>Getting back to work after a longer holiday, my brain might not be running
> >>>>>at full speed here, so I'm trying to clarify things a bit here.
> >>>>>
> >>>>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>>>is similar to what a DMA engine does, except this is slowing down things to
> >>>>>byte level). If that is done properly in the parent node, then we should not
> >>>>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>>>go through the redirection for the children.
> >>>>>
> >>>>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>>>then I agree that the range property should not be required, but also the
> >>>>>reg values need to be changed (drop the top bit). If the later, then the
> >>>>>ranges property is required to do the proper translation.
> >>>>
> >>>>The former, thanks.
> >>>>
> >>>>>
> >>>>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>>>the of_address_to_resource() translation?
> >>>>
> >>>>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>>>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >>>
> >>>Have you tracked what part of the code is sensitive to the presence of "ranges"
> >>>property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >>>
> >>
> >>
> >>Yes, IO_RESOURCE flag can be get without "ranges".

Earlier, you said this ^

> >>I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> >>
> >>of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> >>__of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> >>
> >>
> >>static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> >>			    struct of_bus *pbus, __be32 *addr,
> >>			    int na, int ns, int pna, const char *rprop)
> >>{
> >>	const __be32 *ranges;
> >>	unsigned int rlen;
> >>	int rone;
> >>	u64 offset = OF_BAD_ADDR;
> >>
> >>	ranges = of_get_property(parent, rprop, &rlen);
> >>	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> >>		pr_debug("OF: no ranges; cannot translate\n");
> >>		return 1;
> >>	}
> >>	...
> >>}
> >
> >OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> 
> But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
> the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
> ranges has been discussed.

So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
do you actually get, MMIO is not a valid value.

Liviu

> 
> -- 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/12 19:27, liviu.dudau@arm.com 写道:
> On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
>> 在 2016/1/12 18:14, liviu.dudau@arm.com 写道:
>>> On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
>>>> 在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
>>>>> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>>>>>> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
>>>>>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>>>>>   >
>>>>>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>>>>>   >
>>>>>>>>>>
>>>>>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>>>>>
>>>>>>>>> I tried, and there need some additional changes.
>>>>>>>>>
>>>>>>>>> isa@a01b0000 {
>>>>>>>>>
>>>>>>>>> /*the node name should start with "isa", because of below definition
>>>>>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>>>>>> * {
>>>>>>>>> *	return !strcmp(np->name, "isa");
>>>>>>>>> * }
>>>>>>>>
>>>>>>>> Looks good. It would be nicer to match on device_type than on name,
>>>>>>>> but this is ancient code and it's probably best not to touch it
>>>>>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>>>>>
>>>>>>>>> */
>>>>>>>>> 	compatible = "low-pin-count";
>>>>>>>>> 	device_type = "isa";
>>>>>>>>> 	#address-cells = <2>;
>>>>>>>>> 	#size-cells = <1>;
>>>>>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>>>>>> /*
>>>>>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>>>>>> *
>>>>>>>>> */
>>>>>>>>> 	ipmi_0:ipmi@000000e4{
>>>>>>>>> 		device_type = "ipmi";
>>>>>>>>> 		compatible = "ipmi-bt";
>>>>>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> This looks wrong: the property above says that the I/O port range is
>>>>>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>>>>>> true on your hardware. I think this needs to be changed in the code
>>>>>>>> so the ranges property is not required for I/O ports.
>>>>>>>>
>>>>>>>>> drivers\of\address.c
>>>>>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>>>>>                   const char *name, struct resource *r)
>>>>>>>>> {
>>>>>>>>>           u64 taddr;
>>>>>>>>>
>>>>>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>>>>>                   return -EINVAL;
>>>>>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>>>>>                   return -EINVAL;
>>>>>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>>>>>           if (flags & IORESOURCE_IO) {
>>>>>>>>>                   unsigned long port;
>>>>>>>>>
>>>>>>>>> /*****************************************************************/
>>>>>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>>>>>> /*****************************************************************/
>>>>>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>>>>>                           r->start = taddr;
>>>>>>>>>                           r->end = taddr + size - 1;
>>>>>>>>>                   }
>>>>>>>>
>>>>>>>> I don't like having a special case based on the address here,
>>>>>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>>>>>> hardware that uses an indirect method like your LPC bus
>>>>>>>> does, and the code above will not work on any LPC implementation
>>>>>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>>>>>
>>>>>>>> I think it would be better to avoid translating the port into
>>>>>>>> a physical address to start with just to translate it back into
>>>>>>>> a port number, what we need instead is the offset between the
>>>>>>>> bus specific port number and the linux port number. I've added
>>>>>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>>>>>> of how we could do that.
>>>>>>>
>>>>>>> Hi,
>>>>>>
>>>>>> Hi Liviu,
>>>>>>
>>>>>> Thanks for reviewing this.
>>>>>>
>>>>>>>
>>>>>>> Getting back to work after a longer holiday, my brain might not be running
>>>>>>> at full speed here, so I'm trying to clarify things a bit here.
>>>>>>>
>>>>>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>>>>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>>>>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>>>>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>>>>>> registration? (I have this mental picture that what Rongrong is trying to do
>>>>>>> is similar to what a DMA engine does, except this is slowing down things to
>>>>>>> byte level). If that is done properly in the parent node, then we should not
>>>>>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>>>>>> go through the redirection for the children.
>>>>>>>
>>>>>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>>>>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>>>>>> then I agree that the range property should not be required, but also the
>>>>>>> reg values need to be changed (drop the top bit). If the later, then the
>>>>>>> ranges property is required to do the proper translation.
>>>>>>
>>>>>> The former, thanks.
>>>>>>
>>>>>>>
>>>>>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>>>>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>>>>>> the of_address_to_resource() translation?
>>>>>>
>>>>>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>>>>>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>>>>>
>>>>> Have you tracked what part of the code is sensitive to the presence of "ranges"
>>>>> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>>>>>
>>>>
>>>>
>>>> Yes, IO_RESOURCE flag can be get without "ranges".
>
> Earlier, you said this ^
>
>>>> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
>>>>
>>>> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
>>>> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
>>>>
>>>>
>>>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>>>> 			    struct of_bus *pbus, __be32 *addr,
>>>> 			    int na, int ns, int pna, const char *rprop)
>>>> {
>>>> 	const __be32 *ranges;
>>>> 	unsigned int rlen;
>>>> 	int rone;
>>>> 	u64 offset = OF_BAD_ADDR;
>>>>
>>>> 	ranges = of_get_property(parent, rprop, &rlen);
>>>> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
>>>> 		pr_debug("OF: no ranges; cannot translate\n");
>>>> 		return 1;
>>>> 	}
>>>> 	...
>>>> }
>>>
>>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
>>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
>>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
>>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
>>
>> But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
>> the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
>> ranges has been discussed.
>
> So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
> do you actually get, MMIO is not a valid value.



I'm sorry I did not describe clearly.
Without "ranges", of_get_address() will return with valid value, but of_address_to_resource()
will return with -EINVAL;

int of_address_to_resource(struct device_node *dev, int index,
			   struct resource *r)
{
	...
	/* flags can be get here, without ranges property reqired.
	 * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
	 * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
	 */
	addrp = of_get_address(dev, index, &size, &flags);

	if (addrp == NULL)
		return -EINVAL;

	/* Get optional "reg-names" property to add a name to a resource */
	of_property_read_string_index(dev, "reg-names",	index, &name);


	/* If it is empty ranges, and the flag is IORESOURCE_MEM then the below  __of_address_to_resource return with valid addr,
	 * if it is empty ranges, and the flag is IORESOURCE_IO then return with -EINVAL, because
	 *    pci_address_to_pio() will be called when flag is IORESOURCE_IO.
	 * if the ranges is absent, then return with -EINVAL.
	 */
	return __of_address_to_resource(dev, addrp, size, flags, name, r);
}

I want to get resource with flag = IORESOURCE_IO, resource.start=0XE4, resource.size=0X4,

>
> Liviu
>
>>
>> --
>> Regards,
>> Rongrong
>>
>


-- 
Regards,
Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

? 2016/1/12 19:27, liviu.dudau at arm.com ??:
> On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
>> ? 2016/1/12 18:14, liviu.dudau at arm.com ??:
>>> On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
>>>> ? 2016/1/12 17:07, liviu.dudau at arm.com ??:
>>>>> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>>>>>> On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
>>>>>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>>>> ? 2015/12/31 23:00, Rongrong Zou ??:
>>>>>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
>>>>>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>>>>>   > > ? 2015/12/30 17:06, Arnd Bergmann ??:
>>>>>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>>>>>   >
>>>>>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>>>>>   >
>>>>>>>>>>
>>>>>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>>>>>
>>>>>>>>> I tried, and there need some additional changes.
>>>>>>>>>
>>>>>>>>> isa at a01b0000 {
>>>>>>>>>
>>>>>>>>> /*the node name should start with "isa", because of below definition
>>>>>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>>>>>> * {
>>>>>>>>> *	return !strcmp(np->name, "isa");
>>>>>>>>> * }
>>>>>>>>
>>>>>>>> Looks good. It would be nicer to match on device_type than on name,
>>>>>>>> but this is ancient code and it's probably best not to touch it
>>>>>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>>>>>
>>>>>>>>> */
>>>>>>>>> 	compatible = "low-pin-count";
>>>>>>>>> 	device_type = "isa";
>>>>>>>>> 	#address-cells = <2>;
>>>>>>>>> 	#size-cells = <1>;
>>>>>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>>>>>> /*
>>>>>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>>>>>> *
>>>>>>>>> */
>>>>>>>>> 	ipmi_0:ipmi at 000000e4{
>>>>>>>>> 		device_type = "ipmi";
>>>>>>>>> 		compatible = "ipmi-bt";
>>>>>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> This looks wrong: the property above says that the I/O port range is
>>>>>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>>>>>> true on your hardware. I think this needs to be changed in the code
>>>>>>>> so the ranges property is not required for I/O ports.
>>>>>>>>
>>>>>>>>> drivers\of\address.c
>>>>>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>>>>>                   const char *name, struct resource *r)
>>>>>>>>> {
>>>>>>>>>           u64 taddr;
>>>>>>>>>
>>>>>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>>>>>                   return -EINVAL;
>>>>>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>>>>>                   return -EINVAL;
>>>>>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>>>>>           if (flags & IORESOURCE_IO) {
>>>>>>>>>                   unsigned long port;
>>>>>>>>>
>>>>>>>>> /*****************************************************************/
>>>>>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>>>>>> /*****************************************************************/
>>>>>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>>>>>                           r->start = taddr;
>>>>>>>>>                           r->end = taddr + size - 1;
>>>>>>>>>                   }
>>>>>>>>
>>>>>>>> I don't like having a special case based on the address here,
>>>>>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>>>>>> hardware that uses an indirect method like your LPC bus
>>>>>>>> does, and the code above will not work on any LPC implementation
>>>>>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>>>>>
>>>>>>>> I think it would be better to avoid translating the port into
>>>>>>>> a physical address to start with just to translate it back into
>>>>>>>> a port number, what we need instead is the offset between the
>>>>>>>> bus specific port number and the linux port number. I've added
>>>>>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>>>>>> of how we could do that.
>>>>>>>
>>>>>>> Hi,
>>>>>>
>>>>>> Hi Liviu,
>>>>>>
>>>>>> Thanks for reviewing this.
>>>>>>
>>>>>>>
>>>>>>> Getting back to work after a longer holiday, my brain might not be running
>>>>>>> at full speed here, so I'm trying to clarify things a bit here.
>>>>>>>
>>>>>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>>>>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>>>>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>>>>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>>>>>> registration? (I have this mental picture that what Rongrong is trying to do
>>>>>>> is similar to what a DMA engine does, except this is slowing down things to
>>>>>>> byte level). If that is done properly in the parent node, then we should not
>>>>>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>>>>>> go through the redirection for the children.
>>>>>>>
>>>>>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>>>>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>>>>>> then I agree that the range property should not be required, but also the
>>>>>>> reg values need to be changed (drop the top bit). If the later, then the
>>>>>>> ranges property is required to do the proper translation.
>>>>>>
>>>>>> The former, thanks.
>>>>>>
>>>>>>>
>>>>>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>>>>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>>>>>> the of_address_to_resource() translation?
>>>>>>
>>>>>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>>>>>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>>>>>
>>>>> Have you tracked what part of the code is sensitive to the presence of "ranges"
>>>>> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>>>>>
>>>>
>>>>
>>>> Yes, IO_RESOURCE flag can be get without "ranges".
>
> Earlier, you said this ^
>
>>>> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
>>>>
>>>> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
>>>> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
>>>>
>>>>
>>>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>>>> 			    struct of_bus *pbus, __be32 *addr,
>>>> 			    int na, int ns, int pna, const char *rprop)
>>>> {
>>>> 	const __be32 *ranges;
>>>> 	unsigned int rlen;
>>>> 	int rone;
>>>> 	u64 offset = OF_BAD_ADDR;
>>>>
>>>> 	ranges = of_get_property(parent, rprop, &rlen);
>>>> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
>>>> 		pr_debug("OF: no ranges; cannot translate\n");
>>>> 		return 1;
>>>> 	}
>>>> 	...
>>>> }
>>>
>>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
>>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
>>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
>>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
>>
>> But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
>> the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
>> ranges has been discussed.
>
> So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
> do you actually get, MMIO is not a valid value.



I'm sorry I did not describe clearly.
Without "ranges", of_get_address() will return with valid value, but of_address_to_resource()
will return with -EINVAL;

int of_address_to_resource(struct device_node *dev, int index,
			   struct resource *r)
{
	...
	/* flags can be get here, without ranges property reqired.
	 * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
	 * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
	 */
	addrp = of_get_address(dev, index, &size, &flags);

	if (addrp == NULL)
		return -EINVAL;

	/* Get optional "reg-names" property to add a name to a resource */
	of_property_read_string_index(dev, "reg-names",	index, &name);


	/* If it is empty ranges, and the flag is IORESOURCE_MEM then the below  __of_address_to_resource return with valid addr,
	 * if it is empty ranges, and the flag is IORESOURCE_IO then return with -EINVAL, because
	 *    pci_address_to_pio() will be called when flag is IORESOURCE_IO.
	 * if the ranges is absent, then return with -EINVAL.
	 */
	return __of_address_to_resource(dev, addrp, size, flags, name, r);
}

I want to get resource with flag = IORESOURCE_IO, resource.start=0XE4, resource.size=0X4,

>
> Liviu
>
>>
>> --
>> Regards,
>> Rongrong
>>
>


-- 
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/12 19:27, liviu.dudau@arm.com 写道:
> On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
>> 在 2016/1/12 18:14, liviu.dudau@arm.com 写道:
>>> On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
>>>> 在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
>>>>> On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
>>>>>> On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
>>>>>>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
>>>>>>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
>>>>>>>>> 在 2015/12/31 23:00, Rongrong Zou 写道:
>>>>>>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
>>>>>>>>>>   > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
>>>>>>>>>>   > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
>>>>>>>>>>   > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>>>>>>>>>>   >
>>>>>>>>>>   > The DT sample above looks good in principle. I believe what you are missing
>>>>>>>>>>   > here is code in your driver to scan the child nodes to create the platform
>>>>>>>>>>   > devices. of_bus_isa_translate() should work with your definition here
>>>>>>>>>>   > and create the correct IORESOURCE_IO resources. You don't have any MMIO
>>>>>>>>>>   > resources, so the absence of a ranges property is ok. Maybe all you
>>>>>>>>>>   > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
>>>>>>>>>>   >
>>>>>>>>>>
>>>>>>>>>> You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
>>>>>>>>>> will be sent later. By the way, it's my another email account use when i at home.
>>>>>>>>>
>>>>>>>>> I tried, and there need some additional changes.
>>>>>>>>>
>>>>>>>>> isa@a01b0000 {
>>>>>>>>>
>>>>>>>>> /*the node name should start with "isa", because of below definition
>>>>>>>>> * static int of_bus_isa_match(struct device_node *np)
>>>>>>>>> * {
>>>>>>>>> *	return !strcmp(np->name, "isa");
>>>>>>>>> * }
>>>>>>>>
>>>>>>>> Looks good. It would be nicer to match on device_type than on name,
>>>>>>>> but this is ancient code and it's probably best not to touch it
>>>>>>>> so we don't accidentally break some old SPARC or PPC system.
>>>>>>>>
>>>>>>>>> */
>>>>>>>>> 	compatible = "low-pin-count";
>>>>>>>>> 	device_type = "isa";
>>>>>>>>> 	#address-cells = <2>;
>>>>>>>>> 	#size-cells = <1>;
>>>>>>>>> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>>>>>>> 	ranges = <0x1 0x0 0x0 0x0 0x1000>;
>>>>>>>>> /*
>>>>>>>>> *  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
>>>>>>>>> *
>>>>>>>>> */
>>>>>>>>> 	ipmi_0:ipmi@000000e4{
>>>>>>>>> 		device_type = "ipmi";
>>>>>>>>> 		compatible = "ipmi-bt";
>>>>>>>>> 		reg = <0x1 0x000000e4 0x4>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> This looks wrong: the property above says that the I/O port range is
>>>>>>>> translated to MMIO address 0x00000000 to 0x00010000, which is not
>>>>>>>> true on your hardware. I think this needs to be changed in the code
>>>>>>>> so the ranges property is not required for I/O ports.
>>>>>>>>
>>>>>>>>> drivers\of\address.c
>>>>>>>>> static int __of_address_to_resource(struct device_node *dev,
>>>>>>>>>                   const __be32 *addrp, u64 size, unsigned int flags,
>>>>>>>>>                   const char *name, struct resource *r)
>>>>>>>>> {
>>>>>>>>>           u64 taddr;
>>>>>>>>>
>>>>>>>>>           if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
>>>>>>>>>                   return -EINVAL;
>>>>>>>>>           taddr = of_translate_address(dev, addrp);
>>>>>>>>>           if (taddr == OF_BAD_ADDR)
>>>>>>>>>                   return -EINVAL;
>>>>>>>>>           memset(r, 0, sizeof(struct resource));
>>>>>>>>>           if (flags & IORESOURCE_IO) {
>>>>>>>>>                   unsigned long port;
>>>>>>>>>
>>>>>>>>> /*****************************************************************/
>>>>>>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/
>>>>>>>>> /*****************************************************************/
>>>>>>>>>                   if(taddr + size < PCIBIOS_MIN_IO){
>>>>>>>>>                           r->start = taddr;
>>>>>>>>>                           r->end = taddr + size - 1;
>>>>>>>>>                   }
>>>>>>>>
>>>>>>>> I don't like having a special case based on the address here,
>>>>>>>> the same kind of hack might be needed for PCI I/O spaces in
>>>>>>>> hardware that uses an indirect method like your LPC bus
>>>>>>>> does, and the code above will not work on any LPC implementation
>>>>>>>> that correctly multiplexes its I/O ports with the first PCI domain.
>>>>>>>>
>>>>>>>> I think it would be better to avoid translating the port into
>>>>>>>> a physical address to start with just to translate it back into
>>>>>>>> a port number, what we need instead is the offset between the
>>>>>>>> bus specific port number and the linux port number. I've added
>>>>>>>> Liviu to Cc, he wrote this code originally and may have some idea
>>>>>>>> of how we could do that.
>>>>>>>
>>>>>>> Hi,
>>>>>>
>>>>>> Hi Liviu,
>>>>>>
>>>>>> Thanks for reviewing this.
>>>>>>
>>>>>>>
>>>>>>> Getting back to work after a longer holiday, my brain might not be running
>>>>>>> at full speed here, so I'm trying to clarify things a bit here.
>>>>>>>
>>>>>>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
>>>>>>> added to arm64 by patch 1/3 and redirect those operations to the memory
>>>>>>> mapped LPC driver. I think the whole redirection and registration of inb/outb
>>>>>>> ops can be made cleaner, so that the general concept resembles the DMA ops
>>>>>>> registration? (I have this mental picture that what Rongrong is trying to do
>>>>>>> is similar to what a DMA engine does, except this is slowing down things to
>>>>>>> byte level). If that is done properly in the parent node, then we should not
>>>>>>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
>>>>>>> go through the redirection for the children.
>>>>>>>
>>>>>>> As for the ranges property: does he wants the ipmi-bt driver to see in the
>>>>>>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
>>>>>>> then I agree that the range property should not be required, but also the
>>>>>>> reg values need to be changed (drop the top bit). If the later, then the
>>>>>>> ranges property is required to do the proper translation.
>>>>>>
>>>>>> The former, thanks.
>>>>>>
>>>>>>>
>>>>>>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
>>>>>>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
>>>>>>> the of_address_to_resource() translation?
>>>>>>
>>>>>> I want to get IORESOURCE_IO type resource, but if the parent node drop the
>>>>>> "rangs" property, the of_address_to_resource() translation will return with -EINVAL.
>>>>>
>>>>> Have you tracked what part of the code is sensitive to the presence of "ranges"
>>>>> property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
>>>>>
>>>>
>>>>
>>>> Yes, IO_RESOURCE flag can be get without "ranges".
>
> Earlier, you said this ^
>
>>>> I tracked the code, it is at of_translate_one(), Below is the calling infomation.
>>>>
>>>> of_address_to_resource-> __of_address_to_resource ->of_translate_address->
>>>> __of_translate_address(dev, in_addr, "ranges")->of_translate_one()
>>>>
>>>>
>>>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>>>> 			    struct of_bus *pbus, __be32 *addr,
>>>> 			    int na, int ns, int pna, const char *rprop)
>>>> {
>>>> 	const __be32 *ranges;
>>>> 	unsigned int rlen;
>>>> 	int rone;
>>>> 	u64 offset = OF_BAD_ADDR;
>>>>
>>>> 	ranges = of_get_property(parent, rprop, &rlen);
>>>> 	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
>>>> 		pr_debug("OF: no ranges; cannot translate\n");
>>>> 		return 1;
>>>> 	}
>>>> 	...
>>>> }
>>>
>>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
>>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
>>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
>>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
>>
>> But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
>> the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
>> ranges has been discussed.
>
> So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
> do you actually get, MMIO is not a valid value.



I'm sorry I did not describe clearly.
Without "ranges", of_get_address() will return with valid value, but of_address_to_resource()
will return with -EINVAL;

int of_address_to_resource(struct device_node *dev, int index,
			   struct resource *r)
{
	...
	/* flags can be get here, without ranges property reqired.
	 * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
	 * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
	 */
	addrp = of_get_address(dev, index, &size, &flags);

	if (addrp == NULL)
		return -EINVAL;

	/* Get optional "reg-names" property to add a name to a resource */
	of_property_read_string_index(dev, "reg-names",	index, &name);


	/* If it is empty ranges, and the flag is IORESOURCE_MEM then the below  __of_address_to_resource return with valid addr,
	 * if it is empty ranges, and the flag is IORESOURCE_IO then return with -EINVAL, because
	 *    pci_address_to_pio() will be called when flag is IORESOURCE_IO.
	 * if the ranges is absent, then return with -EINVAL.
	 */
	return __of_address_to_resource(dev, addrp, size, flags, name, r);
}

I want to get resource with flag = IORESOURCE_IO, resource.start=0XE4, resource.size=0X4,

>
> Liviu
>
>>
>> --
>> Regards,
>> Rongrong
>>
>


-- 
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Tue, Jan 12, 2016 at 07:56:47PM +0800, Rongrong Zou wrote:
> 在 2016/1/12 19:27, liviu.dudau@arm.com 写道:
> >On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
> >>在 2016/1/12 18:14, liviu.dudau@arm.com 写道:
> >>>On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> >>>>在 2016/1/12 17:07, liviu.dudau@arm.com 写道:
> >>>>>On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>>>>>On 2016/1/12 0:14, liviu.dudau@arm.com wrote:
> >>>>>>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>>>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>>>>>在 2015/12/31 23:00, Rongrong Zou 写道:
> >>>>>>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd@arndb.de <mailto:arnd@arndb.de>>:
> >>>>>>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>>>>>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >>>>>>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>>>>>  >
> >>>>>>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>>>>>  >
> >>>>>>>>>>
> >>>>>>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>>>>>
> >>>>>>>>>I tried, and there need some additional changes.
> >>>>>>>>>
> >>>>>>>>>isa@a01b0000 {
> >>>>>>>>>
> >>>>>>>>>/*the node name should start with "isa", because of below definition
> >>>>>>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>>>>>* {
> >>>>>>>>>*	return !strcmp(np->name, "isa");
> >>>>>>>>>* }
> >>>>>>>>
> >>>>>>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>>>>>but this is ancient code and it's probably best not to touch it
> >>>>>>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>>>>>
> >>>>>>>>>*/
> >>>>>>>>>	compatible = "low-pin-count";
> >>>>>>>>>	device_type = "isa";
> >>>>>>>>>	#address-cells = <2>;
> >>>>>>>>>	#size-cells = <1>;
> >>>>>>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>>>>>/*
> >>>>>>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>>>>>*
> >>>>>>>>>*/
> >>>>>>>>>	ipmi_0:ipmi@000000e4{
> >>>>>>>>>		device_type = "ipmi";
> >>>>>>>>>		compatible = "ipmi-bt";
> >>>>>>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>>>>>};
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>This looks wrong: the property above says that the I/O port range is
> >>>>>>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>>>>>true on your hardware. I think this needs to be changed in the code
> >>>>>>>>so the ranges property is not required for I/O ports.
> >>>>>>>>
> >>>>>>>>>drivers\of\address.c
> >>>>>>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>>>>>                  const char *name, struct resource *r)
> >>>>>>>>>{
> >>>>>>>>>          u64 taddr;
> >>>>>>>>>
> >>>>>>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>>>>>                  return -EINVAL;
> >>>>>>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>>>>>                  return -EINVAL;
> >>>>>>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>>>>>          if (flags & IORESOURCE_IO) {
> >>>>>>>>>                  unsigned long port;
> >>>>>>>>>
> >>>>>>>>>/*****************************************************************/
> >>>>>>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>>>>>/*****************************************************************/
> >>>>>>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>>>>>                          r->start = taddr;
> >>>>>>>>>                          r->end = taddr + size - 1;
> >>>>>>>>>                  }
> >>>>>>>>
> >>>>>>>>I don't like having a special case based on the address here,
> >>>>>>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>>>>>hardware that uses an indirect method like your LPC bus
> >>>>>>>>does, and the code above will not work on any LPC implementation
> >>>>>>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>>>>>
> >>>>>>>>I think it would be better to avoid translating the port into
> >>>>>>>>a physical address to start with just to translate it back into
> >>>>>>>>a port number, what we need instead is the offset between the
> >>>>>>>>bus specific port number and the linux port number. I've added
> >>>>>>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>>>>>of how we could do that.
> >>>>>>>
> >>>>>>>Hi,
> >>>>>>
> >>>>>>Hi Liviu,
> >>>>>>
> >>>>>>Thanks for reviewing this.
> >>>>>>
> >>>>>>>
> >>>>>>>Getting back to work after a longer holiday, my brain might not be running
> >>>>>>>at full speed here, so I'm trying to clarify things a bit here.
> >>>>>>>
> >>>>>>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>>>>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>>>>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>>>>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>>>>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>>>>>is similar to what a DMA engine does, except this is slowing down things to
> >>>>>>>byte level). If that is done properly in the parent node, then we should not
> >>>>>>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>>>>>go through the redirection for the children.
> >>>>>>>
> >>>>>>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>>>>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>>>>>then I agree that the range property should not be required, but also the
> >>>>>>>reg values need to be changed (drop the top bit). If the later, then the
> >>>>>>>ranges property is required to do the proper translation.
> >>>>>>
> >>>>>>The former, thanks.
> >>>>>>
> >>>>>>>
> >>>>>>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>>>>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>>>>>the of_address_to_resource() translation?
> >>>>>>
> >>>>>>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>>>>>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >>>>>
> >>>>>Have you tracked what part of the code is sensitive to the presence of "ranges"
> >>>>>property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >>>>>
> >>>>
> >>>>
> >>>>Yes, IO_RESOURCE flag can be get without "ranges".
> >
> >Earlier, you said this ^
> >
> >>>>I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> >>>>
> >>>>of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> >>>>__of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> >>>>
> >>>>
> >>>>static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> >>>>			    struct of_bus *pbus, __be32 *addr,
> >>>>			    int na, int ns, int pna, const char *rprop)
> >>>>{
> >>>>	const __be32 *ranges;
> >>>>	unsigned int rlen;
> >>>>	int rone;
> >>>>	u64 offset = OF_BAD_ADDR;
> >>>>
> >>>>	ranges = of_get_property(parent, rprop, &rlen);
> >>>>	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> >>>>		pr_debug("OF: no ranges; cannot translate\n");
> >>>>		return 1;
> >>>>	}
> >>>>	...
> >>>>}
> >>>
> >>>OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >>>only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >>>parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >>>the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> >>
> >>But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
> >>the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
> >>ranges has been discussed.
> >
> >So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
> >do you actually get, MMIO is not a valid value.
> 
> 
> 
> I'm sorry I did not describe clearly.
> Without "ranges", of_get_address() will return with valid value, but of_address_to_resource()
> will return with -EINVAL;
> 
> int of_address_to_resource(struct device_node *dev, int index,
> 			   struct resource *r)
> {
> 	...
> 	/* flags can be get here, without ranges property reqired.
> 	 * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> 	 * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,

That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
of the address and not influence the flags. Can you add some debugging in of_get_address() and
try to figure out what bus is used in  *flags = bus->get_flags(prop) ?

> 	 */
> 	addrp = of_get_address(dev, index, &size, &flags);
> 
> 	if (addrp == NULL)
> 		return -EINVAL;
> 
> 	/* Get optional "reg-names" property to add a name to a resource */
> 	of_property_read_string_index(dev, "reg-names",	index, &name);
> 
> 
> 	/* If it is empty ranges, and the flag is IORESOURCE_MEM then the below  __of_address_to_resource return with valid addr,
> 	 * if it is empty ranges, and the flag is IORESOURCE_IO then return with -EINVAL, because
> 	 *    pci_address_to_pio() will be called when flag is IORESOURCE_IO.
> 	 * if the ranges is absent, then return with -EINVAL.
> 	 */
> 	return __of_address_to_resource(dev, addrp, size, flags, name, r);
> }
> 
> I want to get resource with flag = IORESOURCE_IO, resource.start=0XE4, resource.size=0X4,

Yes, that is what I expect you should get as well.

Liviu

> 
> >
> >Liviu
> >
> >>
> >>--
> >>Regards,
> >>Rongrong
> >>
> >
> 
> 
> -- 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Tue, Jan 12, 2016 at 07:56:47PM +0800, Rongrong Zou wrote:
> ? 2016/1/12 19:27, liviu.dudau at arm.com ??:
> >On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
> >>? 2016/1/12 18:14, liviu.dudau at arm.com ??:
> >>>On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> >>>>? 2016/1/12 17:07, liviu.dudau at arm.com ??:
> >>>>>On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>>>>>On 2016/1/12 0:14, liviu.dudau at arm.com wrote:
> >>>>>>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>>>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>>>>>? 2015/12/31 23:00, Rongrong Zou ??:
> >>>>>>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd at arndb.de <mailto:arnd@arndb.de>>:
> >>>>>>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>>>>>  > > ? 2015/12/30 17:06, Arnd Bergmann ??:
> >>>>>>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>>>>>  >
> >>>>>>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>>>>>  >
> >>>>>>>>>>
> >>>>>>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>>>>>
> >>>>>>>>>I tried, and there need some additional changes.
> >>>>>>>>>
> >>>>>>>>>isa at a01b0000 {
> >>>>>>>>>
> >>>>>>>>>/*the node name should start with "isa", because of below definition
> >>>>>>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>>>>>* {
> >>>>>>>>>*	return !strcmp(np->name, "isa");
> >>>>>>>>>* }
> >>>>>>>>
> >>>>>>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>>>>>but this is ancient code and it's probably best not to touch it
> >>>>>>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>>>>>
> >>>>>>>>>*/
> >>>>>>>>>	compatible = "low-pin-count";
> >>>>>>>>>	device_type = "isa";
> >>>>>>>>>	#address-cells = <2>;
> >>>>>>>>>	#size-cells = <1>;
> >>>>>>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>>>>>/*
> >>>>>>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>>>>>*
> >>>>>>>>>*/
> >>>>>>>>>	ipmi_0:ipmi at 000000e4{
> >>>>>>>>>		device_type = "ipmi";
> >>>>>>>>>		compatible = "ipmi-bt";
> >>>>>>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>>>>>};
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>This looks wrong: the property above says that the I/O port range is
> >>>>>>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>>>>>true on your hardware. I think this needs to be changed in the code
> >>>>>>>>so the ranges property is not required for I/O ports.
> >>>>>>>>
> >>>>>>>>>drivers\of\address.c
> >>>>>>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>>>>>                  const char *name, struct resource *r)
> >>>>>>>>>{
> >>>>>>>>>          u64 taddr;
> >>>>>>>>>
> >>>>>>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>>>>>                  return -EINVAL;
> >>>>>>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>>>>>                  return -EINVAL;
> >>>>>>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>>>>>          if (flags & IORESOURCE_IO) {
> >>>>>>>>>                  unsigned long port;
> >>>>>>>>>
> >>>>>>>>>/*****************************************************************/
> >>>>>>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>>>>>/*****************************************************************/
> >>>>>>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>>>>>                          r->start = taddr;
> >>>>>>>>>                          r->end = taddr + size - 1;
> >>>>>>>>>                  }
> >>>>>>>>
> >>>>>>>>I don't like having a special case based on the address here,
> >>>>>>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>>>>>hardware that uses an indirect method like your LPC bus
> >>>>>>>>does, and the code above will not work on any LPC implementation
> >>>>>>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>>>>>
> >>>>>>>>I think it would be better to avoid translating the port into
> >>>>>>>>a physical address to start with just to translate it back into
> >>>>>>>>a port number, what we need instead is the offset between the
> >>>>>>>>bus specific port number and the linux port number. I've added
> >>>>>>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>>>>>of how we could do that.
> >>>>>>>
> >>>>>>>Hi,
> >>>>>>
> >>>>>>Hi Liviu,
> >>>>>>
> >>>>>>Thanks for reviewing this.
> >>>>>>
> >>>>>>>
> >>>>>>>Getting back to work after a longer holiday, my brain might not be running
> >>>>>>>at full speed here, so I'm trying to clarify things a bit here.
> >>>>>>>
> >>>>>>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>>>>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>>>>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>>>>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>>>>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>>>>>is similar to what a DMA engine does, except this is slowing down things to
> >>>>>>>byte level). If that is done properly in the parent node, then we should not
> >>>>>>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>>>>>go through the redirection for the children.
> >>>>>>>
> >>>>>>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>>>>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>>>>>then I agree that the range property should not be required, but also the
> >>>>>>>reg values need to be changed (drop the top bit). If the later, then the
> >>>>>>>ranges property is required to do the proper translation.
> >>>>>>
> >>>>>>The former, thanks.
> >>>>>>
> >>>>>>>
> >>>>>>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>>>>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>>>>>the of_address_to_resource() translation?
> >>>>>>
> >>>>>>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>>>>>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >>>>>
> >>>>>Have you tracked what part of the code is sensitive to the presence of "ranges"
> >>>>>property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >>>>>
> >>>>
> >>>>
> >>>>Yes, IO_RESOURCE flag can be get without "ranges".
> >
> >Earlier, you said this ^
> >
> >>>>I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> >>>>
> >>>>of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> >>>>__of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> >>>>
> >>>>
> >>>>static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> >>>>			    struct of_bus *pbus, __be32 *addr,
> >>>>			    int na, int ns, int pna, const char *rprop)
> >>>>{
> >>>>	const __be32 *ranges;
> >>>>	unsigned int rlen;
> >>>>	int rone;
> >>>>	u64 offset = OF_BAD_ADDR;
> >>>>
> >>>>	ranges = of_get_property(parent, rprop, &rlen);
> >>>>	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> >>>>		pr_debug("OF: no ranges; cannot translate\n");
> >>>>		return 1;
> >>>>	}
> >>>>	...
> >>>>}
> >>>
> >>>OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >>>only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >>>parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >>>the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> >>
> >>But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
> >>the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
> >>ranges has been discussed.
> >
> >So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
> >do you actually get, MMIO is not a valid value.
> 
> 
> 
> I'm sorry I did not describe clearly.
> Without "ranges", of_get_address() will return with valid value, but of_address_to_resource()
> will return with -EINVAL;
> 
> int of_address_to_resource(struct device_node *dev, int index,
> 			   struct resource *r)
> {
> 	...
> 	/* flags can be get here, without ranges property reqired.
> 	 * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> 	 * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,

That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
of the address and not influence the flags. Can you add some debugging in of_get_address() and
try to figure out what bus is used in  *flags = bus->get_flags(prop) ?

> 	 */
> 	addrp = of_get_address(dev, index, &size, &flags);
> 
> 	if (addrp == NULL)
> 		return -EINVAL;
> 
> 	/* Get optional "reg-names" property to add a name to a resource */
> 	of_property_read_string_index(dev, "reg-names",	index, &name);
> 
> 
> 	/* If it is empty ranges, and the flag is IORESOURCE_MEM then the below  __of_address_to_resource return with valid addr,
> 	 * if it is empty ranges, and the flag is IORESOURCE_IO then return with -EINVAL, because
> 	 *    pci_address_to_pio() will be called when flag is IORESOURCE_IO.
> 	 * if the ranges is absent, then return with -EINVAL.
> 	 */
> 	return __of_address_to_resource(dev, addrp, size, flags, name, r);
> }
> 
> I want to get resource with flag = IORESOURCE_IO, resource.start=0XE4, resource.size=0X4,

Yes, that is what I expect you should get as well.

Liviu

> 
> >
> >Liviu
> >
> >>
> >>--
> >>Regards,
> >>Rongrong
> >>
> >
> 
> 
> -- 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau-5wv7dgnIgG8]

On Tue, Jan 12, 2016 at 07:56:47PM +0800, Rongrong Zou wrote:
> 在 2016/1/12 19:27, liviu.dudau-5wv7dgnIgG8@public.gmane.org 写道:
> >On Tue, Jan 12, 2016 at 07:05:29PM +0800, Rongrong Zou wrote:
> >>在 2016/1/12 18:14, liviu.dudau-5wv7dgnIgG8@public.gmane.org 写道:
> >>>On Tue, Jan 12, 2016 at 05:25:56PM +0800, Rongrong Zou wrote:
> >>>>在 2016/1/12 17:07, liviu.dudau-5wv7dgnIgG8@public.gmane.org 写道:
> >>>>>On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:
> >>>>>>On 2016/1/12 0:14, liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> >>>>>>>On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:
> >>>>>>>>On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
> >>>>>>>>>在 2015/12/31 23:00, Rongrong Zou 写道:
> >>>>>>>>>>2015-12-31 22:40 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org <mailto:arnd-r2nGTMty4D4@public.gmane.org>>:
> >>>>>>>>>>  > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> >>>>>>>>>>  > > 在 2015/12/30 17:06, Arnd Bergmann 写道:
> >>>>>>>>>>  > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >>>>>>>>>>  >
> >>>>>>>>>>  > The DT sample above looks good in principle. I believe what you are missing
> >>>>>>>>>>  > here is code in your driver to scan the child nodes to create the platform
> >>>>>>>>>>  > devices. of_bus_isa_translate() should work with your definition here
> >>>>>>>>>>  > and create the correct IORESOURCE_IO resources. You don't have any MMIO
> >>>>>>>>>>  > resources, so the absence of a ranges property is ok. Maybe all you
> >>>>>>>>>>  > are missing is a call to of_platform_populate() or of_platform_bus_probe()?
> >>>>>>>>>>  >
> >>>>>>>>>>
> >>>>>>>>>>You are right. thanks, i'll try on test board .  if i get the correct result , the new patch
> >>>>>>>>>>will be sent later. By the way, it's my another email account use when i at home.
> >>>>>>>>>
> >>>>>>>>>I tried, and there need some additional changes.
> >>>>>>>>>
> >>>>>>>>>isa@a01b0000 {
> >>>>>>>>>
> >>>>>>>>>/*the node name should start with "isa", because of below definition
> >>>>>>>>>* static int of_bus_isa_match(struct device_node *np)
> >>>>>>>>>* {
> >>>>>>>>>*	return !strcmp(np->name, "isa");
> >>>>>>>>>* }
> >>>>>>>>
> >>>>>>>>Looks good. It would be nicer to match on device_type than on name,
> >>>>>>>>but this is ancient code and it's probably best not to touch it
> >>>>>>>>so we don't accidentally break some old SPARC or PPC system.
> >>>>>>>>
> >>>>>>>>>*/
> >>>>>>>>>	compatible = "low-pin-count";
> >>>>>>>>>	device_type = "isa";
> >>>>>>>>>	#address-cells = <2>;
> >>>>>>>>>	#size-cells = <1>;
> >>>>>>>>>	reg = <0x0 0xa01b0000 0x0 0x10000>;
> >>>>>>>>>	ranges = <0x1 0x0 0x0 0x0 0x1000>;
> >>>>>>>>>/*
> >>>>>>>>>*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>".
> >>>>>>>>>*
> >>>>>>>>>*/
> >>>>>>>>>	ipmi_0:ipmi@000000e4{
> >>>>>>>>>		device_type = "ipmi";
> >>>>>>>>>		compatible = "ipmi-bt";
> >>>>>>>>>		reg = <0x1 0x000000e4 0x4>;
> >>>>>>>>>};
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>This looks wrong: the property above says that the I/O port range is
> >>>>>>>>translated to MMIO address 0x00000000 to 0x00010000, which is not
> >>>>>>>>true on your hardware. I think this needs to be changed in the code
> >>>>>>>>so the ranges property is not required for I/O ports.
> >>>>>>>>
> >>>>>>>>>drivers\of\address.c
> >>>>>>>>>static int __of_address_to_resource(struct device_node *dev,
> >>>>>>>>>                  const __be32 *addrp, u64 size, unsigned int flags,
> >>>>>>>>>                  const char *name, struct resource *r)
> >>>>>>>>>{
> >>>>>>>>>          u64 taddr;
> >>>>>>>>>
> >>>>>>>>>          if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> >>>>>>>>>                  return -EINVAL;
> >>>>>>>>>          taddr = of_translate_address(dev, addrp);
> >>>>>>>>>          if (taddr == OF_BAD_ADDR)
> >>>>>>>>>                  return -EINVAL;
> >>>>>>>>>          memset(r, 0, sizeof(struct resource));
> >>>>>>>>>          if (flags & IORESOURCE_IO) {
> >>>>>>>>>                  unsigned long port;
> >>>>>>>>>
> >>>>>>>>>/*****************************************************************/
> >>>>>>>>>/*legacy port(< 0x1000) is reserved, and need no translation here*/
> >>>>>>>>>/*****************************************************************/
> >>>>>>>>>                  if(taddr + size < PCIBIOS_MIN_IO){
> >>>>>>>>>                          r->start = taddr;
> >>>>>>>>>                          r->end = taddr + size - 1;
> >>>>>>>>>                  }
> >>>>>>>>
> >>>>>>>>I don't like having a special case based on the address here,
> >>>>>>>>the same kind of hack might be needed for PCI I/O spaces in
> >>>>>>>>hardware that uses an indirect method like your LPC bus
> >>>>>>>>does, and the code above will not work on any LPC implementation
> >>>>>>>>that correctly multiplexes its I/O ports with the first PCI domain.
> >>>>>>>>
> >>>>>>>>I think it would be better to avoid translating the port into
> >>>>>>>>a physical address to start with just to translate it back into
> >>>>>>>>a port number, what we need instead is the offset between the
> >>>>>>>>bus specific port number and the linux port number. I've added
> >>>>>>>>Liviu to Cc, he wrote this code originally and may have some idea
> >>>>>>>>of how we could do that.
> >>>>>>>
> >>>>>>>Hi,
> >>>>>>
> >>>>>>Hi Liviu,
> >>>>>>
> >>>>>>Thanks for reviewing this.
> >>>>>>
> >>>>>>>
> >>>>>>>Getting back to work after a longer holiday, my brain might not be running
> >>>>>>>at full speed here, so I'm trying to clarify things a bit here.
> >>>>>>>
> >>>>>>>It looks to me like Rongrong is trying to trap the inb()/outb() calls that he
> >>>>>>>added to arm64 by patch 1/3 and redirect those operations to the memory
> >>>>>>>mapped LPC driver. I think the whole redirection and registration of inb/outb
> >>>>>>>ops can be made cleaner, so that the general concept resembles the DMA ops
> >>>>>>>registration? (I have this mental picture that what Rongrong is trying to do
> >>>>>>>is similar to what a DMA engine does, except this is slowing down things to
> >>>>>>>byte level). If that is done properly in the parent node, then we should not
> >>>>>>>care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always
> >>>>>>>go through the redirection for the children.
> >>>>>>>
> >>>>>>>As for the ranges property: does he wants the ipmi-bt driver to see in the
> >>>>>>>reg property the legacy ISA I/O ports values or the CPU addresses? If the former,
> >>>>>>>then I agree that the range property should not be required, but also the
> >>>>>>>reg values need to be changed (drop the top bit). If the later, then the
> >>>>>>>ranges property is required to do the proper translation.
> >>>>>>
> >>>>>>The former, thanks.
> >>>>>>
> >>>>>>>
> >>>>>>>Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property
> >>>>>>>in the ipmi-bt node, what IO_RESOURCE type resources do you get back from
> >>>>>>>the of_address_to_resource() translation?
> >>>>>>
> >>>>>>I want to get IORESOURCE_IO type resource, but if the parent node drop the
> >>>>>>"rangs" property, the of_address_to_resource() translation will return with -EINVAL.
> >>>>>
> >>>>>Have you tracked what part of the code is sensitive to the presence of "ranges"
> >>>>>property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"?
> >>>>>
> >>>>
> >>>>
> >>>>Yes, IO_RESOURCE flag can be get without "ranges".
> >
> >Earlier, you said this ^
> >
> >>>>I tracked the code, it is at of_translate_one(), Below is the calling infomation.
> >>>>
> >>>>of_address_to_resource-> __of_address_to_resource ->of_translate_address->
> >>>>__of_translate_address(dev, in_addr, "ranges")->of_translate_one()
> >>>>
> >>>>
> >>>>static int of_translate_one(struct device_node *parent, struct of_bus *bus,
> >>>>			    struct of_bus *pbus, __be32 *addr,
> >>>>			    int na, int ns, int pna, const char *rprop)
> >>>>{
> >>>>	const __be32 *ranges;
> >>>>	unsigned int rlen;
> >>>>	int rone;
> >>>>	u64 offset = OF_BAD_ADDR;
> >>>>
> >>>>	ranges = of_get_property(parent, rprop, &rlen);
> >>>>	if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> >>>>		pr_debug("OF: no ranges; cannot translate\n");
> >>>>		return 1;
> >>>>	}
> >>>>	...
> >>>>}
> >>>
> >>>OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >>>only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >>>parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >>>the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> >>
> >>But in this condition, I still can't get the right resource type IORESOURCE_IO, I just get
> >>the MMIO resource E4:E7. Please see the url at https://lkml.org/lkml/2016/1/5/199, the empty
> >>ranges has been discussed.
> >
> >So, when you use an empty "ranges" of_get_address() doesn't return the right flags? What resource
> >do you actually get, MMIO is not a valid value.
> 
> 
> 
> I'm sorry I did not describe clearly.
> Without "ranges", of_get_address() will return with valid value, but of_address_to_resource()
> will return with -EINVAL;
> 
> int of_address_to_resource(struct device_node *dev, int index,
> 			   struct resource *r)
> {
> 	...
> 	/* flags can be get here, without ranges property reqired.
> 	 * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> 	 * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,

That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
of the address and not influence the flags. Can you add some debugging in of_get_address() and
try to figure out what bus is used in  *flags = bus->get_flags(prop) ?

> 	 */
> 	addrp = of_get_address(dev, index, &size, &flags);
> 
> 	if (addrp == NULL)
> 		return -EINVAL;
> 
> 	/* Get optional "reg-names" property to add a name to a resource */
> 	of_property_read_string_index(dev, "reg-names",	index, &name);
> 
> 
> 	/* If it is empty ranges, and the flag is IORESOURCE_MEM then the below  __of_address_to_resource return with valid addr,
> 	 * if it is empty ranges, and the flag is IORESOURCE_IO then return with -EINVAL, because
> 	 *    pci_address_to_pio() will be called when flag is IORESOURCE_IO.
> 	 * if the ranges is absent, then return with -EINVAL.
> 	 */
> 	return __of_address_to_resource(dev, addrp, size, flags, name, r);
> }
> 
> I want to get resource with flag = IORESOURCE_IO, resource.start=0XE4, resource.size=0X4,

Yes, that is what I expect you should get as well.

Liviu

> 
> >
> >Liviu
> >
> >>
> >>--
> >>Regards,
> >>Rongrong
> >>
> >
> 
> 
> -- 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote:
> > int of_address_to_resource(struct device_node *dev, int index,
> >                          struct resource *r)
> > {
> >       ...
> >       /* flags can be get here, without ranges property reqired.
> >        * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> >        * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
> 
> That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
> of the address and not influence the flags. Can you add some debugging in of_get_address() and
> try to figure out what bus is used in  *flags = bus->get_flags(prop) ?
> 
> 

This is the standard ISA binding. The first cell is the address space
(IO or MEM), the second cell is the address within that space. This
is similar to how PCI works.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 12 January 2016 15:13:35 liviu.dudau at arm.com wrote:
> > int of_address_to_resource(struct device_node *dev, int index,
> >                          struct resource *r)
> > {
> >       ...
> >       /* flags can be get here, without ranges property reqired.
> >        * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> >        * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
> 
> That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
> of the address and not influence the flags. Can you add some debugging in of_get_address() and
> try to figure out what bus is used in  *flags = bus->get_flags(prop) ?
> 
> 

This is the standard ISA binding. The first cell is the address space
(IO or MEM), the second cell is the address within that space. This
is similar to how PCI works.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Benjamin Herrenschmidt]

On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote:
> > > int of_address_to_resource(struct device_node *dev, int index,
> > >                          struct resource *r)
> > > {
> > >       ...
> > >       /* flags can be get here, without ranges property reqired.
> > >        * if the reg = <0x0 0xe4 4>, I can get flag of
> IORESOURCE_MEM,
> > >        * if the reg = <0x1 0xe4 4>, I can get flag of
> IORESOURCE_IO,
> > 
> > That is strange, the parent node has #address-cells = <2> so the
> first two numbers should be part
> > of the address and not influence the flags. Can you add some
> debugging in of_get_address() and
> > try to figure out what bus is used in  *flags = bus-
> >get_flags(prop) ?
> > 
> > 
> 
> This is the standard ISA binding. The first cell is the address space
> (IO or MEM), the second cell is the address within that space. This
> is similar to how PCI works.

Picking up that mid-way, I have LPC busses on power and am using a
similar binding. I'll try to grab some examples and review the
document tomorrow (only just noticed it while unpiling emails post-
vacation).

Cheers,
Ben.

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Benjamin Herrenschmidt]

On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 15:13:35 liviu.dudau at arm.com?wrote:
> > > int of_address_to_resource(struct device_node *dev, int index,
> > >????????????????????????? struct resource *r)
> > > {
> > >?????? ...
> > >?????? /* flags can be get here, without ranges property reqired.
> > >??????? * if the reg = <0x0 0xe4 4>, I can get flag of
> IORESOURCE_MEM,
> > >??????? * if the reg = <0x1 0xe4 4>, I can get flag of
> IORESOURCE_IO,
> >?
> > That is strange, the parent node has #address-cells = <2> so the
> first two numbers should be part
> > of the address and not influence the flags. Can you add some
> debugging in of_get_address() and
> > try to figure out what bus is used in? *flags = bus-
> >get_flags(prop) ?
> >?
> >?
> 
> This is the standard ISA binding. The first cell is the address space
> (IO or MEM), the second cell is the address within that space. This
> is similar to how PCI works.

Picking up that mid-way, I have LPC busses on power and am using a
similar binding. I'll try to grab some examples and review the
document tomorrow (only just noticed it while unpiling emails post-
vacation).

Cheers,
Ben.

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Benjamin Herrenschmidt]

On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 15:13:35 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> > > int of_address_to_resource(struct device_node *dev, int index,
> > >                          struct resource *r)
> > > {
> > >       ...
> > >       /* flags can be get here, without ranges property reqired.
> > >        * if the reg = <0x0 0xe4 4>, I can get flag of
> IORESOURCE_MEM,
> > >        * if the reg = <0x1 0xe4 4>, I can get flag of
> IORESOURCE_IO,
> > 
> > That is strange, the parent node has #address-cells = <2> so the
> first two numbers should be part
> > of the address and not influence the flags. Can you add some
> debugging in of_get_address() and
> > try to figure out what bus is used in  *flags = bus-
> >get_flags(prop) ?
> > 
> > 
> 
> This is the standard ISA binding. The first cell is the address space
> (IO or MEM), the second cell is the address within that space. This
> is similar to how PCI works.

Picking up that mid-way, I have LPC busses on power and am using a
similar binding. I'll try to grab some examples and review the
document tomorrow (only just noticed it while unpiling emails post-
vacation).

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/13 13:53, Benjamin Herrenschmidt wrote:
> On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
>> On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote:
>>>> int of_address_to_resource(struct device_node *dev, int index,
>>>>                            struct resource *r)
>>>> {
>>>>         ...
>>>>         /* flags can be get here, without ranges property reqired.
>>>>          * if the reg = <0x0 0xe4 4>, I can get flag of
>> IORESOURCE_MEM,
>>>>          * if the reg = <0x1 0xe4 4>, I can get flag of
>> IORESOURCE_IO,
>>>
>>> That is strange, the parent node has #address-cells = <2> so the
>> first two numbers should be part
>>> of the address and not influence the flags. Can you add some
>> debugging in of_get_address() and
>>> try to figure out what bus is used in  *flags = bus-
>>> get_flags(prop) ?
>>>
>>>
>>
>> This is the standard ISA binding. The first cell is the address space
>> (IO or MEM), the second cell is the address within that space. This
>> is similar to how PCI works.
>
> Picking up that mid-way, I have LPC busses on power and am using a
> similar binding. I'll try to grab some examples and review the
> document tomorrow (only just noticed it while unpiling emails post-
> vacation).

Hi Ben,
Thanks for reviewing this, I found a similar implementation at arch/powerpc/
platform/powernv/opal-lpc.c and I had get some ideas from your work. It is
nice to me. I'm expecting your suggestion.Thanks in advance.

>
> Cheers,
> Ben.
>
Regards,
Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/13 13:53, Benjamin Herrenschmidt wrote:
> On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
>> On Tuesday 12 January 2016 15:13:35 liviu.dudau at arm.com wrote:
>>>> int of_address_to_resource(struct device_node *dev, int index,
>>>>                            struct resource *r)
>>>> {
>>>>         ...
>>>>         /* flags can be get here, without ranges property reqired.
>>>>          * if the reg = <0x0 0xe4 4>, I can get flag of
>> IORESOURCE_MEM,
>>>>          * if the reg = <0x1 0xe4 4>, I can get flag of
>> IORESOURCE_IO,
>>>
>>> That is strange, the parent node has #address-cells = <2> so the
>> first two numbers should be part
>>> of the address and not influence the flags. Can you add some
>> debugging in of_get_address() and
>>> try to figure out what bus is used in  *flags = bus-
>>> get_flags(prop) ?
>>>
>>>
>>
>> This is the standard ISA binding. The first cell is the address space
>> (IO or MEM), the second cell is the address within that space. This
>> is similar to how PCI works.
>
> Picking up that mid-way, I have LPC busses on power and am using a
> similar binding. I'll try to grab some examples and review the
> document tomorrow (only just noticed it while unpiling emails post-
> vacation).

Hi Ben,
Thanks for reviewing this, I found a similar implementation at arch/powerpc/
platform/powernv/opal-lpc.c and I had get some ideas from your work. It is
nice to me. I'm expecting your suggestion.Thanks in advance.

>
> Cheers,
> Ben.
>
Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/13 13:53, Benjamin Herrenschmidt wrote:
> On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
>> On Tuesday 12 January 2016 15:13:35 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
>>>> int of_address_to_resource(struct device_node *dev, int index,
>>>>                            struct resource *r)
>>>> {
>>>>         ...
>>>>         /* flags can be get here, without ranges property reqired.
>>>>          * if the reg = <0x0 0xe4 4>, I can get flag of
>> IORESOURCE_MEM,
>>>>          * if the reg = <0x1 0xe4 4>, I can get flag of
>> IORESOURCE_IO,
>>>
>>> That is strange, the parent node has #address-cells = <2> so the
>> first two numbers should be part
>>> of the address and not influence the flags. Can you add some
>> debugging in of_get_address() and
>>> try to figure out what bus is used in  *flags = bus-
>>> get_flags(prop) ?
>>>
>>>
>>
>> This is the standard ISA binding. The first cell is the address space
>> (IO or MEM), the second cell is the address within that space. This
>> is similar to how PCI works.
>
> Picking up that mid-way, I have LPC busses on power and am using a
> similar binding. I'll try to grab some examples and review the
> document tomorrow (only just noticed it while unpiling emails post-
> vacation).

Hi Ben,
Thanks for reviewing this, I found a similar implementation at arch/powerpc/
platform/powernv/opal-lpc.c and I had get some ideas from your work. It is
nice to me. I'm expecting your suggestion.Thanks in advance.

>
> Cheers,
> Ben.
>
Regards,
Rongrong
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 14:34:47 Rongrong Zou wrote:
> On 2016/1/13 13:53, Benjamin Herrenschmidt wrote:
> > On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
> >> On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote:
> >>>> int of_address_to_resource(struct device_node *dev, int index,
> >>>>                            struct resource *r)
> >>>> {
> >>>>         ...
> >>>>         /* flags can be get here, without ranges property reqired.
> >>>>          * if the reg = <0x0 0xe4 4>, I can get flag of
> >> IORESOURCE_MEM,
> >>>>          * if the reg = <0x1 0xe4 4>, I can get flag of
> >> IORESOURCE_IO,
> >>>
> >>> That is strange, the parent node has #address-cells = <2> so the
> >> first two numbers should be part
> >>> of the address and not influence the flags. Can you add some
> >> debugging in of_get_address() and
> >>> try to figure out what bus is used in  *flags = bus-
> >>> get_flags(prop) ?
> >>>
> >>>
> >>
> >> This is the standard ISA binding. The first cell is the address space
> >> (IO or MEM), the second cell is the address within that space. This
> >> is similar to how PCI works.
> >
> > Picking up that mid-way, I have LPC busses on power and am using a
> > similar binding. I'll try to grab some examples and review the
> > document tomorrow (only just noticed it while unpiling emails post-
> > vacation).

I really should have thought of that, as you mentioned already that
there is an ast2400 on those machines, and no I/O space on the PCI
bus.

Too bad we have to keep the I/O workarounds alive on PowerPC now,
I was already hoping they could go away after spider-pci gets phased
out.

> Thanks for reviewing this, I found a similar implementation at arch/powerpc/
> platform/powernv/opal-lpc.c and I had get some ideas from your work. It is
> nice to me. I'm expecting your suggestion.Thanks in advance.

Unfortunately, the way that PCI host bridges on PowerPC are handled
is a bit different from what we do on ARM64, otherwise the obvious
solution would be to move the I/O workarounds to an architecture
independent location. Maybe it's still possible, but that also requires
some refactoring then.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 14:34:47 Rongrong Zou wrote:
> On 2016/1/13 13:53, Benjamin Herrenschmidt wrote:
> > On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
> >> On Tuesday 12 January 2016 15:13:35 liviu.dudau at arm.com wrote:
> >>>> int of_address_to_resource(struct device_node *dev, int index,
> >>>>                            struct resource *r)
> >>>> {
> >>>>         ...
> >>>>         /* flags can be get here, without ranges property reqired.
> >>>>          * if the reg = <0x0 0xe4 4>, I can get flag of
> >> IORESOURCE_MEM,
> >>>>          * if the reg = <0x1 0xe4 4>, I can get flag of
> >> IORESOURCE_IO,
> >>>
> >>> That is strange, the parent node has #address-cells = <2> so the
> >> first two numbers should be part
> >>> of the address and not influence the flags. Can you add some
> >> debugging in of_get_address() and
> >>> try to figure out what bus is used in  *flags = bus-
> >>> get_flags(prop) ?
> >>>
> >>>
> >>
> >> This is the standard ISA binding. The first cell is the address space
> >> (IO or MEM), the second cell is the address within that space. This
> >> is similar to how PCI works.
> >
> > Picking up that mid-way, I have LPC busses on power and am using a
> > similar binding. I'll try to grab some examples and review the
> > document tomorrow (only just noticed it while unpiling emails post-
> > vacation).

I really should have thought of that, as you mentioned already that
there is an ast2400 on those machines, and no I/O space on the PCI
bus.

Too bad we have to keep the I/O workarounds alive on PowerPC now,
I was already hoping they could go away after spider-pci gets phased
out.

> Thanks for reviewing this, I found a similar implementation at arch/powerpc/
> platform/powernv/opal-lpc.c and I had get some ideas from your work. It is
> nice to me. I'm expecting your suggestion.Thanks in advance.

Unfortunately, the way that PCI host bridges on PowerPC are handled
is a bit different from what we do on ARM64, otherwise the obvious
solution would be to move the I/O workarounds to an architecture
independent location. Maybe it's still possible, but that also requires
some refactoring then.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 14:34:47 Rongrong Zou wrote:
> On 2016/1/13 13:53, Benjamin Herrenschmidt wrote:
> > On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote:
> >> On Tuesday 12 January 2016 15:13:35 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> >>>> int of_address_to_resource(struct device_node *dev, int index,
> >>>>                            struct resource *r)
> >>>> {
> >>>>         ...
> >>>>         /* flags can be get here, without ranges property reqired.
> >>>>          * if the reg = <0x0 0xe4 4>, I can get flag of
> >> IORESOURCE_MEM,
> >>>>          * if the reg = <0x1 0xe4 4>, I can get flag of
> >> IORESOURCE_IO,
> >>>
> >>> That is strange, the parent node has #address-cells = <2> so the
> >> first two numbers should be part
> >>> of the address and not influence the flags. Can you add some
> >> debugging in of_get_address() and
> >>> try to figure out what bus is used in  *flags = bus-
> >>> get_flags(prop) ?
> >>>
> >>>
> >>
> >> This is the standard ISA binding. The first cell is the address space
> >> (IO or MEM), the second cell is the address within that space. This
> >> is similar to how PCI works.
> >
> > Picking up that mid-way, I have LPC busses on power and am using a
> > similar binding. I'll try to grab some examples and review the
> > document tomorrow (only just noticed it while unpiling emails post-
> > vacation).

I really should have thought of that, as you mentioned already that
there is an ast2400 on those machines, and no I/O space on the PCI
bus.

Too bad we have to keep the I/O workarounds alive on PowerPC now,
I was already hoping they could go away after spider-pci gets phased
out.

> Thanks for reviewing this, I found a similar implementation at arch/powerpc/
> platform/powernv/opal-lpc.c and I had get some ideas from your work. It is
> nice to me. I'm expecting your suggestion.Thanks in advance.

Unfortunately, the way that PCI host bridges on PowerPC are handled
is a bit different from what we do on ARM64, otherwise the obvious
solution would be to move the I/O workarounds to an architecture
independent location. Maybe it's still possible, but that also requires
some refactoring then.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Tue, Jan 12, 2016 at 11:52:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote:
> > > int of_address_to_resource(struct device_node *dev, int index,
> > >                          struct resource *r)
> > > {
> > >       ...
> > >       /* flags can be get here, without ranges property reqired.
> > >        * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> > >        * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
> > 
> > That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
> > of the address and not influence the flags. Can you add some debugging in of_get_address() and
> > try to figure out what bus is used in  *flags = bus->get_flags(prop) ?
> > 
> > 
> 
> This is the standard ISA binding. The first cell is the address space
> (IO or MEM), the second cell is the address within that space. This
> is similar to how PCI works.

OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
should the reg not be something like reg = <0x1 0x0 0xe4 4> ?

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Tue, Jan 12, 2016 at 11:52:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 15:13:35 liviu.dudau at arm.com wrote:
> > > int of_address_to_resource(struct device_node *dev, int index,
> > >                          struct resource *r)
> > > {
> > >       ...
> > >       /* flags can be get here, without ranges property reqired.
> > >        * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> > >        * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
> > 
> > That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
> > of the address and not influence the flags. Can you add some debugging in of_get_address() and
> > try to figure out what bus is used in  *flags = bus->get_flags(prop) ?
> > 
> > 
> 
> This is the standard ISA binding. The first cell is the address space
> (IO or MEM), the second cell is the address within that space. This
> is similar to how PCI works.

OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
should the reg not be something like reg = <0x1 0x0 0xe4 4> ?

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau-5wv7dgnIgG8]

On Tue, Jan 12, 2016 at 11:52:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 15:13:35 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> > > int of_address_to_resource(struct device_node *dev, int index,
> > >                          struct resource *r)
> > > {
> > >       ...
> > >       /* flags can be get here, without ranges property reqired.
> > >        * if the reg = <0x0 0xe4 4>, I can get flag of IORESOURCE_MEM,
> > >        * if the reg = <0x1 0xe4 4>, I can get flag of IORESOURCE_IO,
> > 
> > That is strange, the parent node has #address-cells = <2> so the first two numbers should be part
> > of the address and not influence the flags. Can you add some debugging in of_get_address() and
> > try to figure out what bus is used in  *flags = bus->get_flags(prop) ?
> > 
> > 
> 
> This is the standard ISA binding. The first cell is the address space
> (IO or MEM), the second cell is the address within that space. This
> is similar to how PCI works.

OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
should the reg not be something like reg = <0x1 0x0 0xe4 4> ?

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 10:10:28 liviu.dudau@arm.com wrote:
> 
> OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
> should the reg not be something like reg = <0x1 0x0 0xe4 4> ?

No: 2+1 = 3, not 4.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 10:10:28 liviu.dudau at arm.com wrote:
> 
> OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
> should the reg not be something like reg = <0x1 0x0 0xe4 4> ?

No: 2+1 = 3, not 4.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Wed, Jan 13, 2016 at 11:18:11AM +0100, Arnd Bergmann wrote:
> On Wednesday 13 January 2016 10:10:28 liviu.dudau@arm.com wrote:
> > 
> > OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
> > should the reg not be something like reg = <0x1 0x0 0xe4 4> ?
> 
> No: 2+1 = 3, not 4.

Bah, not enough caffeine this morning, forgot the flags are part of the address space. Sorry for inept noise.

Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Wed, Jan 13, 2016 at 11:18:11AM +0100, Arnd Bergmann wrote:
> On Wednesday 13 January 2016 10:10:28 liviu.dudau at arm.com wrote:
> > 
> > OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
> > should the reg not be something like reg = <0x1 0x0 0xe4 4> ?
> 
> No: 2+1 = 3, not 4.

Bah, not enough caffeine this morning, forgot the flags are part of the address space. Sorry for inept noise.

Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau-5wv7dgnIgG8]

On Wed, Jan 13, 2016 at 11:18:11AM +0100, Arnd Bergmann wrote:
> On Wednesday 13 January 2016 10:10:28 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> > 
> > OK, but from DT point of view and given the parent's #address-cells = <2> and #size-cells = <1>
> > should the reg not be something like reg = <0x1 0x0 0xe4 4> ?
> 
> No: 2+1 = 3, not 4.

Bah, not enough caffeine this morning, forgot the flags are part of the address space. Sorry for inept noise.

Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 12 January 2016 10:14:18 liviu.dudau@arm.com wrote:
> 
> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> 
> 

A missing ranges property means that there is no translation, while an
empty ranges means a 1:1 translation to the parent bus.

We really want the former here, as I/O port addresses are not mapped into
the MMIO space of the parent bus.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Tuesday 12 January 2016 10:14:18 liviu.dudau at arm.com wrote:
> 
> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> 
> 

A missing ranges property means that there is no translation, while an
empty ranges means a 1:1 translation to the parent bus.

We really want the former here, as I/O port addresses are not mapped into
the MMIO space of the parent bus.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 10:14:18 liviu.dudau@arm.com wrote:
> > 
> > OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> > only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> > parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> > the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> > 
> > 
> 
> A missing ranges property means that there is no translation, while an
> empty ranges means a 1:1 translation to the parent bus.
> 
> We really want the former here, as I/O port addresses are not mapped into
> the MMIO space of the parent bus.

Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
useful suggestions on what the right behaviour should be.

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 10:14:18 liviu.dudau at arm.com wrote:
> > 
> > OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> > only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> > parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> > the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> > 
> > 
> 
> A missing ranges property means that there is no translation, while an
> empty ranges means a 1:1 translation to the parent bus.
> 
> We really want the former here, as I/O port addresses are not mapped into
> the MMIO space of the parent bus.

Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
useful suggestions on what the right behaviour should be.

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau-5wv7dgnIgG8]

On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 10:14:18 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> > 
> > OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> > only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> > parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> > the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> > 
> > 
> 
> A missing ranges property means that there is no translation, while an
> empty ranges means a 1:1 translation to the parent bus.
> 
> We really want the former here, as I/O port addresses are not mapped into
> the MMIO space of the parent bus.

Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
useful suggestions on what the right behaviour should be.

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 10:09:11 liviu.dudau@arm.com wrote:
> On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> > On Tuesday 12 January 2016 10:14:18 liviu.dudau@arm.com wrote:
> > > 
> > > OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> > > only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> > > parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> > > the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> > > 
> > > 
> > 
> > A missing ranges property means that there is no translation, while an
> > empty ranges means a 1:1 translation to the parent bus.
> > 
> > We really want the former here, as I/O port addresses are not mapped into
> > the MMIO space of the parent bus.
> 
> Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> useful suggestions on what the right behaviour should be.

I believe of_get_address() already has the correct number (local to the
ISA/LPC bus here), an we just need to teach __of_address_to_resource
about ISA buses that have their own translation. We have the device
node of the ISA bus here, so we just need to stop translating further
using the ranges property and instead use the io_offset for that bus.

In fact we can use the same method for both ISA and PCI buses, if
we just remember which device node is the root for an I/O space
and what its offset is relative to the Linux I/O space. Going all
the way to a physical CPU address and then back to an I/O port number
through pci_address_to_pio() is awkward anyway, but here it's wrong
specifically because there is no physical address for it.

	Arnd

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 10:09:11 liviu.dudau at arm.com wrote:
> On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> > On Tuesday 12 January 2016 10:14:18 liviu.dudau at arm.com wrote:
> > > 
> > > OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> > > only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> > > parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> > > the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> > > 
> > > 
> > 
> > A missing ranges property means that there is no translation, while an
> > empty ranges means a 1:1 translation to the parent bus.
> > 
> > We really want the former here, as I/O port addresses are not mapped into
> > the MMIO space of the parent bus.
> 
> Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> useful suggestions on what the right behaviour should be.

I believe of_get_address() already has the correct number (local to the
ISA/LPC bus here), an we just need to teach __of_address_to_resource
about ISA buses that have their own translation. We have the device
node of the ISA bus here, so we just need to stop translating further
using the ranges property and instead use the io_offset for that bus.

In fact we can use the same method for both ISA and PCI buses, if
we just remember which device node is the root for an I/O space
and what its offset is relative to the Linux I/O space. Going all
the way to a physical CPU address and then back to an I/O port number
through pci_address_to_pio() is awkward anyway, but here it's wrong
specifically because there is no physical address for it.

	Arnd

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Arnd Bergmann]

On Wednesday 13 January 2016 10:09:11 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> > On Tuesday 12 January 2016 10:14:18 liviu.dudau-5wv7dgnIgG8@public.gmane.org wrote:
> > > 
> > > OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> > > only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> > > parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> > > the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> > > 
> > > 
> > 
> > A missing ranges property means that there is no translation, while an
> > empty ranges means a 1:1 translation to the parent bus.
> > 
> > We really want the former here, as I/O port addresses are not mapped into
> > the MMIO space of the parent bus.
> 
> Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> useful suggestions on what the right behaviour should be.

I believe of_get_address() already has the correct number (local to the
ISA/LPC bus here), an we just need to teach __of_address_to_resource
about ISA buses that have their own translation. We have the device
node of the ISA bus here, so we just need to stop translating further
using the ranges property and instead use the io_offset for that bus.

In fact we can use the same method for both ISA and PCI buses, if
we just remember which device node is the root for an I/O space
and what its offset is relative to the Linux I/O space. Going all
the way to a physical CPU address and then back to an I/O port number
through pci_address_to_pio() is awkward anyway, but here it's wrong
specifically because there is no physical address for it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/13 18:09, liviu.dudau@arm.com wrote:
> On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
>> On Tuesday 12 January 2016 10:14:18 liviu.dudau@arm.com wrote:
>>>
>>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
>>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
>>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
>>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
>>>
>>>
>>
>> A missing ranges property means that there is no translation, while an
>> empty ranges means a 1:1 translation to the parent bus.
>>
>> We really want the former here, as I/O port addresses are not mapped into
>> the MMIO space of the parent bus.
>
> Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> useful suggestions on what the right behaviour should be.
>

I had tried to modify the drivers/of/address.c to address this problem, but it looks
not so general. I'm not sure you have seen this: https://lkml.org/lkml/2016/1/10/89 .

Regards,
Rongrong

[PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/13 18:09, liviu.dudau at arm.com wrote:
> On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
>> On Tuesday 12 January 2016 10:14:18 liviu.dudau at arm.com wrote:
>>>
>>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
>>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
>>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
>>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
>>>
>>>
>>
>> A missing ranges property means that there is no translation, while an
>> empty ranges means a 1:1 translation to the parent bus.
>>
>> We really want the former here, as I/O port addresses are not mapped into
>> the MMIO space of the parent bus.
>
> Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> useful suggestions on what the right behaviour should be.
>

I had tried to modify the drivers/of/address.c to address this problem, but it looks
not so general. I'm not sure you have seen this: https://lkml.org/lkml/2016/1/10/89 .

Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau]

On Wed, Jan 13, 2016 at 07:06:42PM +0800, Rongrong Zou wrote:
> On 2016/1/13 18:09, liviu.dudau@arm.com wrote:
> >On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> >>On Tuesday 12 January 2016 10:14:18 liviu.dudau@arm.com wrote:
> >>>
> >>>OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >>>only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >>>parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >>>the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> >>>
> >>>
> >>
> >>A missing ranges property means that there is no translation, while an
> >>empty ranges means a 1:1 translation to the parent bus.
> >>
> >>We really want the former here, as I/O port addresses are not mapped into
> >>the MMIO space of the parent bus.
> >
> >Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> >useful suggestions on what the right behaviour should be.
> >
> 
> I had tried to modify the drivers/of/address.c to address this problem, but it looks
> not so general. I'm not sure you have seen this: https://lkml.org/lkml/2016/1/10/89 .

Yes, I have seen it. Based on Arnd's suggestion, it is probably the way to go.

Best regards,
Liviu

> 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v1 3/3] ARM64 LPC: update binding doc

[liviu.dudau at arm.com]

On Wed, Jan 13, 2016 at 07:06:42PM +0800, Rongrong Zou wrote:
> On 2016/1/13 18:09, liviu.dudau at arm.com wrote:
> >On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote:
> >>On Tuesday 12 January 2016 10:14:18 liviu.dudau at arm.com wrote:
> >>>
> >>>OK, looking at of_translate_one() comments it looks like a missing "ranges" property is
> >>>only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa
> >>>parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have
> >>>the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>;
> >>>
> >>>
> >>
> >>A missing ranges property means that there is no translation, while an
> >>empty ranges means a 1:1 translation to the parent bus.
> >>
> >>We really want the former here, as I/O port addresses are not mapped into
> >>the MMIO space of the parent bus.
> >
> >Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no
> >useful suggestions on what the right behaviour should be.
> >
> 
> I had tried to modify the drivers/of/address.c to address this problem, but it looks
> not so general. I'm not sure you have seen this: https://lkml.org/lkml/2016/1/10/89 .

Yes, I have seen it. Based on Arnd's suggestion, it is probably the way to go.

Best regards,
Liviu

> 
> Regards,
> Rongrong
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Benjamin Herrenschmidt]

On Tue, 2015-12-29 at 21:33 +0800, Rongrong Zou wrote:
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
>  .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> new file mode 100644
> index 0000000..215f2c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> @@ -0,0 +1,20 @@
> +Low Pin Count bus driver
> +
> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
> +port locate on LPC bus can be accessed directly. But some SoC have
> +independent LPC controller, and we can access the legacy port by specifying
> +LPC address cycle. Thus, LPC driver is introduced.
> +
> +Required properties:
> +- compatible: "low-pin-count"

I'm not sure about the above. I'd rather just make it "isa" or maybe
isa-lpc. The LPC bus is fundamentally an ISA bus with the 3 cycle
types of ISA etc... I would also allow the node to be named "isa".

> +- reg: specifies low pin count address range
> +
> +
> +Example:
> +
> +        lpc_0: lpc@a01b0000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;

As discussed earlier, address-cells should be 2 with the first cell
indicating the address space type (0 = mem, 1 = IO, possibly 2 =
firmware but that remains somewhat TBD).
 
> +                compatible = "low-pin-count";
> +                reg = <0x0 0xa01b0000 0x0 0x10000>;

And also as discussed, this is the business of the "ranges" property so
that children devices can be properly expressed.

> +        };

Also, this being a bus binding, it should describe the format for
children (for example, PNP related properties).

That leads to the obvious question: Why not just reference the existing
Open Firmware ISA binding ?

Cheers,
Ben.

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/14 7:29, Benjamin Herrenschmidt wrote:
> On Tue, 2015-12-29 at 21:33 +0800, Rongrong Zou wrote:
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>>   .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> new file mode 100644
>> index 0000000..215f2c4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> @@ -0,0 +1,20 @@
>> +Low Pin Count bus driver
>> +
>> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
>> +port locate on LPC bus can be accessed directly. But some SoC have
>> +independent LPC controller, and we can access the legacy port by specifying
>> +LPC address cycle. Thus, LPC driver is introduced.
>> +
>> +Required properties:
>> +- compatible: "low-pin-count"
>
> I'm not sure about the above. I'd rather just make it "isa" or maybe
> isa-lpc. The LPC bus is fundamentally an ISA bus with the 3 cycle
> types of ISA etc... I would also allow the node to be named "isa".

I had modified its name to "isa@****", otherwise, the kernel do not
understand its children devices are on ISA bus.
>
>> +- reg: specifies low pin count address range
>> +
>> +
>> +Example:
>> +
>> +        lpc_0: lpc@a01b0000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>
> As discussed earlier, address-cells should be 2 with the first cell
> indicating the address space type (0 = mem, 1 = IO, possibly 2 =
> firmware but that remains somewhat TBD).
>
>> +                compatible = "low-pin-count";
>> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>
> And also as discussed, this is the business of the "ranges" property so
> that children devices can be properly expressed.
>

As discussed before,
 > A missing ranges property means that there is no translation, while an
 > empty ranges means a 1:1 translation to the parent bus.
 > We really want the former here, as I/O port addresses are not mapped into
 > the MMIO space of the parent bus.

>> +        };
>
> Also, this being a bus binding, it should describe the format for
> children (for example, PNP related properties).
>
> That leads to the obvious question: Why not just reference the existing
> Open Firmware ISA binding ?

Unfortunately, I found all these bindings are based on memory-mapped I/O.
Such as below binding I found in arch/x86/platform/ce4100/falconfalls.dts
                 pci@3fc {
                         #address-cells = <3>;
                         #size-cells = <2>;
                         compatible = "intel,ce4100-pci", "pci";
                         device_type = "pci";
                         bus-range = <0 0>;
                         ranges = <0x2000000 0 0xbffff000 0xbffff000 0 0x1000
                                   0x2000000 0 0xdffe0000 0xdffe0000 0 0x1000
                                   0x0000000 0 0x0        0x0        0 0x100>;

                         isa@1f,0 {
                                 #address-cells = <2>;
                                 #size-cells = <1>;
                                 compatible = "isa";
                                 reg = <0xf800 0x0 0x0 0x0 0x0>;
                                 ranges = <1 0 0 0 0 0x100>;

                                 rtc@70 {
                                         compatible = "intel,ce4100-rtc", "motorola,mc146818";
                                         interrupts = <8 3>;
                                         interrupt-parent = <&ioapic1>;
                                         ctrl-reg = <2>;
                                         freq-reg = <0x26>;
                                         reg = <1 0x70 2>;
                                 };
                         };
                 };

Regards,
Rongrong

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Benjamin Herrenschmidt]

On Thu, 2016-01-14 at 10:03 +0800, Rongrong Zou wrote:
> On 2016/1/14 7:29, Benjamin Herrenschmidt wrote:
> > On Tue, 2015-12-29 at 21:33 +0800, Rongrong Zou wrote:
> > > Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> > > ---
> > >   .../devicetree/bindings/arm64/low-pin-count.txt      | 20
> > > ++++++++++++++++++++
> > >   1 file changed, 20 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/arm64/low-
> > > pin-count.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm64/low-pin-
> > > count.txt b/Documentation/devicetree/bindings/arm64/low-pin-
> > > count.txt
> > > new file mode 100644
> > > index 0000000..215f2c4
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> > > @@ -0,0 +1,20 @@
> > > +Low Pin Count bus driver
> > > +
> > > +Usually LPC controller is part of PCI host bridge, so the legacy
> > > ISA
> > > +port locate on LPC bus can be accessed directly. But some SoC
> > > have
> > > +independent LPC controller, and we can access the legacy port by
> > > specifying
> > > +LPC address cycle. Thus, LPC driver is introduced.
> > > +
> > > +Required properties:
> > > +- compatible: "low-pin-count"
> > 
> > I'm not sure about the above. I'd rather just make it "isa" or
> > maybe
> > isa-lpc. The LPC bus is fundamentally an ISA bus with the 3 cycle
> > types of ISA etc... I would also allow the node to be named "isa".
> 
> I had modified its name to "isa@****", otherwise, the kernel do not
> understand its children devices are on ISA bus.

Right, and the "compatible" property should be something like the
specific implementation of the LPC bridge. For example, ibm,power8-lpc
in my case. Not something generic.

Maybe we could allow for a generic one if the LPC is directly MMIO
mapped via the ranges property.

> > > +- reg: specifies low pin count address range
> > > +
> > > +
> > > +Example:
> > > +
> > > +        lpc_0: lpc@a01b0000 {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <1>;
> > 
> > As discussed earlier, address-cells should be 2 with the first cell
> > indicating the address space type (0 = mem, 1 = IO, possibly 2 =
> > firmware but that remains somewhat TBD).
> > 
> > > +                compatible = "low-pin-count";
> > > +                reg = <0x0 0xa01b0000 0x0 0x10000>;
> > 
> > And also as discussed, this is the business of the "ranges"
> > property so
> > that children devices can be properly expressed.
> > 
> 
> As discussed before,
>  > A missing ranges property means that there is no translation,
> while an
>  > empty ranges means a 1:1 translation to the parent bus.
>  > We really want the former here, as I/O port addresses are not
> mapped into
>  > the MMIO space of the parent bus.

Right ok but then it's not a generic binding for "low-pin-count". It's
a specific binding for that specific vendor LPC controller. In that
case yes, reg contains the registers for it but your compatible
property should be more precise.

For a generic binding of LPC, you'd want a ranges property though.

> > > +        };
> > 
> > Also, this being a bus binding, it should describe the format for
> > children (for example, PNP related properties).
> > 
> > That leads to the obvious question: Why not just reference the
> > existing
> > Open Firmware ISA binding ?
> 
> Unfortunately, I found all these bindings are based on memory-mapped
> I/O.

You should still refer to it for the definition of the properties of
children of the LPC.

Basically, a generic LPC bus is an ISA bus and honors the ISA binding.
A specific LPC controller provides a method of generating the ISA bus
cycles. If it's memory mapped, it can just stay generic and use a
ranges property. If not, it's more specific, thus has no range and has
a reg and a *precise* compatible property.

But that shouldn't affect the definition of the children nodes.


> Such as below binding I found in
> arch/x86/platform/ce4100/falconfalls.dts
>                  pci@3fc {
>                          #address-cells = <3>;
>                          #size-cells = <2>;
>                          compatible = "intel,ce4100-pci", "pci";
>                          device_type = "pci";
>                          bus-range = <0 0>;
>                          ranges = <0x2000000 0 0xbffff000 0xbffff000
> 0 0x1000
>                                    0x2000000 0 0xdffe0000 0xdffe0000
> 0 0x1000
>                                    0x0000000 0
> 0x0        0x0        0 0x100>;
> 
>                          isa@1f,0 {
>                                  #address-cells = <2>;
>                                  #size-cells = <1>;
>                                  compatible = "isa";
>                                  reg = <0xf800 0x0 0x0 0x0 0x0>;
>                                  ranges = <1 0 0 0 0 0x100>;
> 
>                                  rtc@70 {
>                                          compatible = "intel,ce4100-
> rtc", "motorola,mc146818";
>                                          interrupts = <8 3>;
>                                          interrupt-parent =
> <&ioapic1>;
>                                          ctrl-reg = <2>;
>                                          freq-reg = <0x26>;
>                                          reg = <1 0x70 2>;
>                                  };
>                          };
>                  };

Yes that's a generic one.

Cheers,
Ben.

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/14 11:39, Benjamin Herrenschmidt wrote:
> On Thu, 2016-01-14 at 10:03 +0800, Rongrong Zou wrote:
>> On 2016/1/14 7:29, Benjamin Herrenschmidt wrote:
>>> On Tue, 2015-12-29 at 21:33 +0800, Rongrong Zou wrote:
>>>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>>>> ---
>>>>    .../devicetree/bindings/arm64/low-pin-count.txt      | 20
>>>> ++++++++++++++++++++
>>>>    1 file changed, 20 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm64/low-
>>>> pin-count.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-
>>>> count.txt b/Documentation/devicetree/bindings/arm64/low-pin-
>>>> count.txt
>>>> new file mode 100644
>>>> index 0000000..215f2c4
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>>>> @@ -0,0 +1,20 @@
>>>> +Low Pin Count bus driver
>>>> +
>>>> +Usually LPC controller is part of PCI host bridge, so the legacy
>>>> ISA
>>>> +port locate on LPC bus can be accessed directly. But some SoC
>>>> have
>>>> +independent LPC controller, and we can access the legacy port by
>>>> specifying
>>>> +LPC address cycle. Thus, LPC driver is introduced.
>>>> +
>>>> +Required properties:
>>>> +- compatible: "low-pin-count"
>>>
>>> I'm not sure about the above. I'd rather just make it "isa" or
>>> maybe
>>> isa-lpc. The LPC bus is fundamentally an ISA bus with the 3 cycle
>>> types of ISA etc... I would also allow the node to be named "isa".
>>
>> I had modified its name to "isa@****", otherwise, the kernel do not
>> understand its children devices are on ISA bus.
>
> Right, and the "compatible" property should be something like the
> specific implementation of the LPC bridge. For example, ibm,power8-lpc
> in my case. Not something generic.
>
> Maybe we could allow for a generic one if the LPC is directly MMIO
> mapped via the ranges property.

It is not directly MMIO mapped actually.

>
>>>> +- reg: specifies low pin count address range
>>>> +
>>>> +
>>>> +Example:
>>>> +
>>>> +        lpc_0: lpc@a01b0000 {
>>>> +		#address-cells = <1>;
>>>> +		#size-cells = <1>;
>>>
>>> As discussed earlier, address-cells should be 2 with the first cell
>>> indicating the address space type (0 = mem, 1 = IO, possibly 2 =
>>> firmware but that remains somewhat TBD).
>>>
>>>> +                compatible = "low-pin-count";
>>>> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>>>
>>> And also as discussed, this is the business of the "ranges"
>>> property so
>>> that children devices can be properly expressed.
>>>
>>
>> As discussed before,
>>   > A missing ranges property means that there is no translation,
>> while an
>>   > empty ranges means a 1:1 translation to the parent bus.
>>   > We really want the former here, as I/O port addresses are not
>> mapped into
>>   > the MMIO space of the parent bus.
>
> Right ok but then it's not a generic binding for "low-pin-count". It's
> a specific binding for that specific vendor LPC controller. In that
> case yes, reg contains the registers for it but your compatible
> property should be more precise.

Yes, it is a vendor-specific LPC controller. The compatible property here
  is too general :)

>
> For a generic binding of LPC, you'd want a ranges property though.
>
>>>> +        };
>>>
>>> Also, this being a bus binding, it should describe the format for
>>> children (for example, PNP related properties).
>>>
>>> That leads to the obvious question: Why not just reference the
>>> existing
>>> Open Firmware ISA binding ?
>>
>> Unfortunately, I found all these bindings are based on memory-mapped
>> I/O.
>
> You should still refer to it for the definition of the properties of
> children of the LPC.
>
> Basically, a generic LPC bus is an ISA bus and honors the ISA binding.
> A specific LPC controller provides a method of generating the ISA bus
> cycles. If it's memory mapped, it can just stay generic and use a
> ranges property. If not, it's more specific, thus has no range and has
> a reg and a *precise* compatible property.
>
> But that shouldn't affect the definition of the children nodes.

The big problem is we do not want the "ranges" property, but we can't get
resource if the property is absent, you could see discussion at
https://lkml.org/lkml/2016/1/11/631.

>
>
>> Such as below binding I found in
>> arch/x86/platform/ce4100/falconfalls.dts
>>                   pci@3fc {
>>                           #address-cells = <3>;
>>                           #size-cells = <2>;
>>                           compatible = "intel,ce4100-pci", "pci";
>>                           device_type = "pci";
>>                           bus-range = <0 0>;
>>                           ranges = <0x2000000 0 0xbffff000 0xbffff000
>> 0 0x1000
>>                                     0x2000000 0 0xdffe0000 0xdffe0000
>> 0 0x1000
>>                                     0x0000000 0
>> 0x0        0x0        0 0x100>;
>>
>>                           isa@1f,0 {
>>                                   #address-cells = <2>;
>>                                   #size-cells = <1>;
>>                                   compatible = "isa";
>>                                   reg = <0xf800 0x0 0x0 0x0 0x0>;
>>                                   ranges = <1 0 0 0 0 0x100>;
>>
>>                                   rtc@70 {
>>                                           compatible = "intel,ce4100-
>> rtc", "motorola,mc146818";
>>                                           interrupts = <8 3>;
>>                                           interrupt-parent =
>> <&ioapic1>;
>>                                           ctrl-reg = <2>;
>>                                           freq-reg = <0x26>;
>>                                           reg = <1 0x70 2>;
>>                                   };
>>                           };
>>                   };
>
> Yes that's a generic one.
>
> Cheers,
> Ben.
>

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Benjamin Herrenschmidt]

On Thu, 2016-01-14 at 12:42 +0800, Rongrong Zou wrote:

> > Right, and the "compatible" property should be something like the
> > specific implementation of the LPC bridge. For example, ibm,power8-
> > lpc
> > in my case. Not something generic.
> > 
> > Maybe we could allow for a generic one if the LPC is directly MMIO
> > mapped via the ranges property.
> 
> It is not directly MMIO mapped actually.

I know yours is not. But some are. My point is that we should have a
binding that is either completely specific to your ARM64 LPC or we
should have a generic LPC binding with provisions for implementation
specific stuff such as ARM64 or POWER8 which are both not MMIO mapped.

I go for the latter.

So "ranges" if you are mapped, otherwise "reg", and in the latter case,
the compatible property should be much more specific like it is for P8,

  .../...

> The big problem is we do not want the "ranges" property, but we can't
> get resource if the property is absent, you could see discussion at
> https://lkml.org/lkml/2016/1/11/631.

That's fixable. I missed the discussion but I'll have a look tomorrow.

Cheers
Ben.

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

On 2016/1/14 19:25, Benjamin Herrenschmidt wrote:
> On Thu, 2016-01-14 at 12:42 +0800, Rongrong Zou wrote:
>
>>> Right, and the "compatible" property should be something like the
>>> specific implementation of the LPC bridge. For example, ibm,power8-
>>> lpc
>>> in my case. Not something generic.
>>>
>>> Maybe we could allow for a generic one if the LPC is directly MMIO
>>> mapped via the ranges property.
>>
>> It is not directly MMIO mapped actually.
>
> I know yours is not. But some are. My point is that we should have a
> binding that is either completely specific to your ARM64 LPC or we
> should have a generic LPC binding with provisions for implementation
> specific stuff such as ARM64 or POWER8 which are both not MMIO mapped.

Yes, that is what I want, both mapped and unmapped IO should
better be supported.

>
> I go for the latter.
>
> So "ranges" if you are mapped, otherwise "reg", and in the latter case,
> the compatible property should be much more specific like it is for P8,
>
>    .../...
>
>> The big problem is we do not want the "ranges" property, but we can't
>> get resource if the property is absent, you could see discussion at
>> https://lkml.org/lkml/2016/1/11/631.
>
> That's fixable. I missed the discussion but I'll have a look tomorrow.
>
> Cheers
> Ben.
>

Regars,
Rongrong