devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Chen <hzpeterchen@gmail.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH V2 0/1] usb: add HCD providers
Date: Thu, 14 Jul 2016 17:48:36 +0800	[thread overview]
Message-ID: <20160714094836.GB28730@shlinux2> (raw)
In-Reply-To: <CACna6rxscQAE_hrM7Rnsntp5QZjL2kD0+mbuXgfo6kPQZ=UDJw@mail.gmail.com>

On Wed, Jul 13, 2016 at 04:40:53PM +0200, Rafał Miłecki wrote:
> On 13 July 2016 at 15:50, Felipe Balbi <felipe.balbi@linux.intel.com> wrote:
> > Rafał Miłecki <zajec5@gmail.com> writes:
> >> On 13 July 2016 at 15:20, Felipe Balbi <felipe.balbi@linux.intel.com> wrote:
> >>> Rafał Miłecki <zajec5@gmail.com> writes:
> >>>> Hi again,
> >>>>
> >>>> This is my second try of getting HCD providers into usb subsystem.
> >>>>
> >>>> During discussion of V1 I realized there are about 26 drivers adding a
> >>>> single HCD and all of them would need to be modified. So instead I
> >>>> decided to put relevant code in usb_add_hcd. It checks if the HCD we
> >>>> register is a primary one and if so, it registers a proper provider.
> >>>>
> >>>> Please note that of_hcd_xlate_simple was also extended to allow getting
> >>>> shared HCD (which is used e.g. in case of XHCI).
> >>>>
> >>>> So now you can have something like:
> >>>>
> >>>> ohci: ohci@21000 {
> >>>>       #usb-cells = <0>;
> >>>>       compatible = "generic-ohci";
> >>>>       reg = <0x00001000 0x1000>;
> >>>>       interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> >>>> };
> >>>>
> >>>> ehci: ehci@22000 {
> >>>>       #usb-cells = <0>;
> >>>>       compatible = "generic-ehci";
> >>>>       reg = <0x00002000 0x1000>;
> >>>>       interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> >>>> };
> >>>>
> >>>> xhci: xhci@23000 {
> >>>>       #usb-cells = <1>;
> >>>>       compatible = "generic-xhci";
> >>>>       reg = <0x00003000 0x1000>;
> >>>>       interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> >>>> };
> >>>>
> >>>> The last (second) patch is not supposed to be applied, it's used only as
> >>>> a proof and example of how providers can be used.
> >>>
> >>> nowhere here (or in previous patch) you clarify why exactly you need
> >>> this. What is your LED trigger supposed to do? Why can't it handle ports
> >>> changing number in different boots? Why do we need this at all? Why is
> >>> your code DT-specific?
> >>>
> >>> There are still too many 'unknowns' here.
> >>
> >> Are you sure you saw my reply to Peter's question?
> >> <CACna6rw6QOuY247qvDmO4mKrW3y4yXoeM3qr8SXAwn3CuYAMpw@mail.gmail.com>
> >> http://www.spinics.net/lists/linux-usb/msg143708.html
> >> http://marc.info/?l=linux-usb&m=146838735627093&w=2
> >>
> >> I think it should answer (some of?) your questions. Can you read it
> >> and see if it gets a bit clearer?
> >
> > well, all that says is that you're writing a LED trigger to toggle LED
> > when a USB device gets added to a specified port. I don't think you need
> > the actual port number for that. You should have a phandle to the actual
> > port, whatever its number is, or a phandle to the (root-)Hub and a port
> > number from that hub.
> >
> > The problem, really, is that DT descriptor of USB Hosts is very, very
> > minimal. Perhaps there's something more extensively defined from the
> > original Open Firmware USB Addendum.
> 
> Thanks for your effort and looking at this closely. You're right, I'm
> interested in referencing USB ports, but I'm using controller phandle
> (and then I specify ports manually).
> 
> Having each port described by DT would be helpful, it's just something
> I didn't find implemented, so I started looking for different ways. It
> seems I should have picked a different solution.
> 
> So should I work on describing USB ports in DT instead? This looks
> like a complex thing to describe, so I'd like to ask for some guidance
> first. What do you think about following schema/example?
> 
> ohci@1000 {
>         compatible = "generic-ohci";
>         reg = <0x00001000 0x1000>;
>         interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> 
>         primary-hcd {
>                 ohci_port0: port@0 {
>                         reg = <0>;
>                 };
> 
>                 ohci_port1: port@1 {
>                         reg = <1>;
>                 };
>         }
> };
> 
> ehci@2000 {
>         compatible = "generic-ehci";
>         reg = <0x00002000 0x1000>;
>         interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> 
>         primary-hcd {
>                 ehci_port0: port@0 {
>                         reg = <0>;
>                 };
> 
>                 ehci_port1: port@1 {
>                         reg = <1>;
>                 };
>         }
> };
> 
> xhci@3000 {
>         compatible = "generic-xhci";
>         reg = <0x00003000 0x1000>;
>         interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> 
>         primary-hcd {
>         };
> 
>         shared-hcd {
>                 xhci_port0: port@0 {
>                         reg = <0>;
>                 };
>         }
> };
> 
> With such a DT struct, how could I query port for a Linux-assigned number?
> 
> For example with OHCI, EHCI and XHCI drivers compiled, Linux assigns
> number 4 to my XHCI's shared HCD's root hub:
> xhci-hcd 18023000.xhci: xHCI Host Controller
> xhci-hcd 18023000.xhci: new USB bus registered, assigned bus number 4
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 1 port detected
> 
> If I disable OHCI and EHCI I get:
> xhci-hcd xhci-hcd.0: xHCI Host Controller
> xhci-hcd xhci-hcd.0: new USB bus registered, assigned bus number 2
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 1 port detected
> 
> So I need my "usbport" trigger driver to be able to get "4-1" in the
> first case and "2-1" in the second case. I guess I should use
> &xhci_port0 but what then? How could I translate it into
> Linux-assigned numbering?
> 

For your current design, you need to fix shared hcd for xHCI problem,
since xHCI has two buses.

Below I supply another thought, please check if it is feasible.
In below design, you don't need to change any usb codes.

dts:

led_1 {
	led_gpio_1;
	usb_port = &ohci_port0, &ehci_port1;
}

led_2 {
	led_gpio_2;
	usb_port = &xhci_port0, &xhci_port1;
}

ohci@1000 {
        compatible = "generic-ohci";
        reg = <0x00001000 0x1000>;
        interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;

	ohci_port0: port@0 {
		reg = <0>;
	};

	ohci_port1: port@1 {
		reg = <1>;
	};
};

ehci@2000 {
        compatible = "generic-ehci";
        reg = <0x00002000 0x1000>;
        interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;

	ehci_port0: port@0 {
		reg = <0>;
	};

	ehci_port1: port@1 {
		reg = <1>;
	};
};

xhci@3000 {
        compatible = "generic-xhci";
        reg = <0x00003000 0x1000>;
        interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;

	/* for xhci, port 0 - [N-1] is USB3, N - [M-1] is USB2/1.
	 * The port 0 and port N is the same physical port
	 */
	xhci_port0: port@0 {
		reg = <0>;
	};

	xhci_port1: port@1 {
		reg = <1>;
	};

};

At code, compare the usb_device's device_node at usbport_trig_notify
if it is at led_1's usb device list, light on it.

-- 

Best Regards,
Peter Chen

  reply	other threads:[~2016-07-14  9:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12 12:35 [PATCH 0/2] usb: add HCD providers Rafał Miłecki
2016-07-12 12:35 ` [PATCH 1/2] usb: core: add support for " Rafał Miłecki
     [not found]   ` <1468326921-26485-2-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-09 13:56     ` Greg Kroah-Hartman
2016-07-12 12:35 ` [PATCH 2/2] ohci-platform: register HCD provider Rafał Miłecki
2016-07-12 12:35 ` [PATCH PROOF OF CONCEPT 3/2] trigger: ledtrig-usbport: read initial state from DT Rafał Miłecki
2016-07-13  4:51 ` [PATCH 0/2] usb: add HCD providers Peter Chen
2016-07-13  5:21   ` Rafał Miłecki
     [not found]     ` <CACna6rw6QOuY247qvDmO4mKrW3y4yXoeM3qr8SXAwn3CuYAMpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-13  8:02       ` Peter Chen
2016-07-13  9:31         ` Rafał Miłecki
     [not found] ` <1468326921-26485-1-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-13 12:42   ` [PATCH V2 0/1] " Rafał Miłecki
     [not found]     ` <1468413734-9569-1-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-13 12:42       ` [PATCH V2 1/1] usb: core: add support for " Rafał Miłecki
2016-07-13 12:42       ` [PATCH V2 PROOF OF CONCEPT 2/1] trigger: ledtrig-usbport: read initial state from DT Rafał Miłecki
     [not found]         ` <1468413734-9569-3-git-send-email-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-13 14:48           ` Jacek Anaszewski
     [not found]             ` <578654A7.2020909-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-07-13 15:05               ` Rafał Miłecki
2016-07-13 13:20     ` [PATCH V2 0/1] usb: add HCD providers Felipe Balbi
     [not found]       ` <87lh15isi7.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-07-13 13:34         ` Rafał Miłecki
     [not found]           ` <CACna6rxGN5evQhRpNORUP4RP3-pMa292pQW=4=VWLLnzJyhJJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-13 13:50             ` Felipe Balbi
     [not found]               ` <87inw9ir4k.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-07-13 14:40                 ` Rafał Miłecki
2016-07-14  9:48                   ` Peter Chen [this message]
2016-07-14 10:05                     ` Felipe Balbi
2016-07-14 15:52                     ` Rafał Miłecki
2016-07-15  2:28                       ` Peter Chen
2016-07-15  5:48                         ` Rafał Miłecki
2016-07-15  6:22                           ` Peter Chen
2016-07-15  9:35                             ` Rafał Miłecki

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=20160714094836.GB28730@shlinux2 \
    --to=hzpeterchen@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).