From: zourongrong@huawei•com (Rongrong Zou)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v1 3/3] ARM64 LPC: update binding doc
Date: Thu, 7 Jan 2016 11:37:35 +0800 [thread overview]
Message-ID: <568DDD7F.5040909@huawei.com> (raw)
In-Reply-To: <568D1861.1070201@huawei.com>
? 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
next prev parent reply other threads:[~2016-01-07 3:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1451396032-23708-1-git-send-email-zourongrong@gmail.com>
[not found] ` <1899302.RWIn6Bg3Dr@wuerfel>
[not found] ` <568537C3.3060902@huawei.com>
[not found] ` <17750582.ajK78gYOFz@wuerfel>
[not found] ` <CABTftiT1+AmrNjiAie-T6on-oWA4Zz73+Tj2pQrixMT3o475uw@mail.gmail.com>
2016-01-03 12:24 ` [PATCH v1 3/3] ARM64 LPC: update binding doc Rongrong Zou
2016-01-04 11:13 ` Arnd Bergmann
2016-01-04 16:04 ` Rongrong Zou
2016-01-04 16:34 ` Arnd Bergmann
2016-01-05 11:59 ` Rongrong Zou
2016-01-05 12:19 ` Arnd Bergmann
2016-01-06 13:36 ` Rongrong Zou
2016-01-07 3:37 ` Rongrong Zou [this message]
2016-01-10 9:29 ` Rolland Chau
2016-01-10 13:38 ` Rongrong Zou
2016-01-11 16:14 ` liviu.dudau at arm.com
2016-01-12 2:39 ` Rongrong Zou
2016-01-12 9:07 ` liviu.dudau at arm.com
2016-01-12 9:25 ` Rongrong Zou
2016-01-12 10:14 ` liviu.dudau at arm.com
2016-01-12 11:05 ` Rongrong Zou
2016-01-12 11:27 ` liviu.dudau at arm.com
2016-01-12 11:56 ` Rongrong Zou
2016-01-12 15:13 ` liviu.dudau at arm.com
2016-01-12 22:52 ` Arnd Bergmann
2016-01-13 5:53 ` Benjamin Herrenschmidt
2016-01-13 6:34 ` Rongrong Zou
2016-01-13 9:26 ` Arnd Bergmann
2016-01-13 10:10 ` liviu.dudau at arm.com
2016-01-13 10:18 ` Arnd Bergmann
2016-01-13 10:32 ` liviu.dudau at arm.com
2016-01-12 22:54 ` Arnd Bergmann
2016-01-13 10:09 ` liviu.dudau at arm.com
2016-01-13 10:29 ` Arnd Bergmann
2016-01-13 11:06 ` Rongrong Zou
2016-01-13 11:25 ` liviu.dudau at arm.com
[not found] ` <1628979.qkJQGmVH0I@wuerfel>
[not found] ` <5683A3B4.7040005@huawei.com>
[not found] ` <23432380.Bk9bdl2Z0r@wuerfel>
[not found] ` <20160104101124.GA1616@arm.com>
2016-01-04 10:27 ` [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Rongrong Zou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=568DDD7F.5040909@huawei.com \
--to=zourongrong@huawei$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox