On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote:

On 2016/1/12 0:14, liviu.dudau@arm.com wrote:

quoted

On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote:

quoted

On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:

quoted

在 2015/12/31 23:00, Rongrong Zou 写道:

quoted

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.

quoted

*/
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.

quoted

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.

quoted

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.

quoted

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

quoted

Best regards,
Liviu

quoted

Arnd

Regards,
Rongrong

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