* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Peter Chen @ 2016-09-26 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147457026249.9057.8712383708019243942@sboyd-linaro>
On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-16 18:16:05)
> > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > we need to change this mux to forward the D+/D- lines to either
> > > > the port or the hub. Therefore, introduce a driver for this
> > > > device that intercepts extcon USB_HOST events and logically
> > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > attached. When the cable goes away, it will logically deassert
> > > > the gpio and mux the "device" lines.
> > > >
> > > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > >
> > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > > Cc: <devicetree@vger.kernel.org>
> > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > ---
> > > >
> > > > Should I make the extcon part optional? I could see a case where there are two
> > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > software may want to mux between them at runtime. If we mandate an extcon,
> > > > that won't be possible to support. Perhaps it would be better to have
> > > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > > endpoints would be useful too) so that when the controller wants to mux over
> > > > a port it can do so.
> > >
> > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > haven't written any code around it, but the idea is to allow the binding
> > > to specify how the mux is connected to upstream and downstream D+/D-
> > > lines. This way, we can do some dt parsing of the endpoints and their
> > > parent nodes to figure out if the mux needs to be set high or low to use
> > > a device connector or a usb hub based on if the id cable is present.
> > > Maybe I'm over thinking things though and we could just have a DT
> > > property for that.
> > >
> > > soc {
> > > usb at 78d9000 {
> > > extcon = <&usb_id>, <&usb_id>;
> >
> > Why you have two same extcon phandler? From my mind, one should id,
> > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > vbus support, how you support vbus detection for
> > connection/disconnection with PC for your chipidea msm patch set?
>
> This was already in the dts files for db410c. In the chipidea binding
> one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> that great on this board because we only have on gpio for this.
I think extcon-usb-gpio.c needs to extend for supporting vbus event,
otherwise, the micro-b cable's connect/disconnect will introduce
EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
vbus event.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Sören Brinkmann @ 2016-09-26 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474818243-19207-1-git-send-email-weiyj.lk@gmail.com>
On Sun, 2016-09-25 at 15:44:03 +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
> symbol 'sdhci_arasan_reset' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
S?ren
^ permalink raw reply
* [PATCH] cpufreq: st: add missing \n to end of dev_err message
From: Viresh Kumar @ 2016-09-26 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160925214013.12430-1-colin.king@canonical.com>
On 25-09-16, 14:40, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_err message is missing a \n, so add it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/cpufreq/sti-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> index 0404203..b366e6d 100644
> --- a/drivers/cpufreq/sti-cpufreq.c
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -163,7 +163,7 @@ static int sti_cpufreq_set_opp_info(void)
>
> reg_fields = sti_cpufreq_match();
> if (!reg_fields) {
> - dev_err(dev, "This SoC doesn't support voltage scaling");
> + dev_err(dev, "This SoC doesn't support voltage scaling\n");
> return -ENODEV;
> }
>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
From: Viresh Kumar @ 2016-09-26 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912215515.GF7243@codeaurora.org>
On 12-09-16, 14:55, Stephen Boyd wrote:
> On 08/29, Viresh Kumar wrote:
> > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > + struct cpufreq_frequency_table *table,
> > > + int volt)
> > > +{
> > > + struct opp_table *opp_table;
> > > + struct cpufreq_frequency_table *pos;
> > > + struct dev_pm_opp *opp;
> > > +
> > > + if (!volt)
> > > + return 0;
> > > +
> > > + rcu_read_lock();
> > > +
> > > + opp_table = _find_opp_table(cpu_dev);
> > > + if (IS_ERR(opp_table)) {
> > > + rcu_read_unlock();
> > > + return PTR_ERR(opp_table);
> > > + }
> > > +
> > > + cpufreq_for_each_valid_entry(pos, table) {
> > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > + true);
> > > + if (IS_ERR(opp))
> > > + continue;
> > > +
> > > + opp->u_volt += volt;
> > > + opp->u_volt_min += volt;
> > > + opp->u_volt_max += volt;
> > > + }
> > > +
> > > + rcu_read_unlock();
> > > +
> > > + return 0;
> > > +}
> >
> > I wouldn't prefer altering the opp tables from individual drivers at all. At the
> > least, it should be done via some helpers exposed by the core.
> >
> > But before that I would like to hear from Stephen a bit as I recall he was also
> > working on something similar.
> >
>
> I had a patch to modify the voltage at runtime for the "current"
> OPP. Now that we have regulator and clk control inside OPP that
> became a little easier to do without having to do some notifier
> from the OPP layer to the consumers. I haven't had time to revive
> those patches though. Should we do that?
Perhaps yes, we should have a common place for doing all that.
> Does this need to modify
> anything besides the OPP the device is currently running at?
Finlye, can you please answer this ?
--
viresh
^ permalink raw reply
* [PATCH v2 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Viresh Kumar @ 2016-09-26 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E555B3.2010304@ti.com>
On 23-09-16, 11:17, Dave Gerlach wrote:
> On 09/23/2016 12:19 AM, Viresh Kumar wrote:
> >On 21-09-16, 14:34, Dave Gerlach wrote:
> >>Viresh,
> >>On 09/07/2016 10:39 PM, Viresh Kumar wrote:
> >>>On 07-09-16, 10:04, Dave Gerlach wrote:
> >>>>>>+static const struct of_device_id ti_cpufreq_of_match[] = {
> >>>>>>+ { .compatible = "operating-points-v2-ti-am3352-cpu",
> >>>>>>+ .data = &am3x_soc_data, },
> >>>>>>+ { .compatible = "operating-points-v2-ti-am4372-cpu",
> >>>>>>+ .data = &am4x_soc_data, },
> >>>>>>+ { .compatible = "operating-points-v2-ti-dra7-cpu",
> >>>>>>+ .data = &dra7_soc_data },
> >>>>>
> >>>>>You should be using your SoC compatible strings here. OPP compatible
> >>>>>property isn't supposed to be (mis)used for this purpose.
> >>>>>
> >>>>
> >>>>Referring to my comments in patch 1, what if we end up changing the bindings
> >>>>based on DT maintainer comments? We will have these compatible strings, and
> >>>>at that point is it acceptable to match against them? Or is it still better
> >>>>to match to SoC compatibles? I think it makes sense to just probe against
> >>>>these.
> >>>
> >>>But even then I think these are not correct. You should have added a
> >>>single compatible string: operating-points-v2-ti-cpu.
> >>>
> >>>As the properties will stay the same across machines. And then you
> >>>need to use SoC strings here.
> >>>
> >>
> >>Are you opposed to moving _of_get_opp_desc_node from
> >>drivers/base/power/opp/opp.h to include/linux/pm_opp.h and renaming it
> >>appropriately?
> >
> >I am not opposed to that, but ...
> >
> >>If I move the ti properties out of the cpu node, as discussed in patch 1 of
> >>this series, and into the operating-points-v2 table, I need a way to get the
> >>operating-points-v2 device node and I think it makes sense to reuse this as
> >>it is what the opp framework uses internally to parse the phandle to the opp
> >>table.
> >
> >I am not sure if those registers belong to the OPP bindings. What are those
> >registers really? What all can be read from them? Why shouldn't they be present
> >as a separate node in DT on the respective bus? Look at how it is done for
> >sti-cpufreq driver.
> >
>
> The sti-cpufreq driver in v4.8-rc7 appears to do what I am already doing in
> this revision of the patch, reading from a syscon phandle that is part of
> the cpu node in the DT which is what I was told not to do.
>
> The register I am referencing in the syscon is a bit-field describing which
> OPPs are valid for the system, so it is very relevant to the OPP binding.
> They really are already present in a separate node, I'm just indexing into a
> syscon, same as the sti-cpufreq driver appears to be doing.
Okay, you can move that function out.
--
viresh
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Baruch Siach @ 2016-09-26 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-3-git-send-email-vz@mleia.com>
Hi Vladimir,
On Mon, Sep 26, 2016 at 03:39:21AM +0300, Vladimir Zapolskiy wrote:
> Watchdog device controller found on all modern SoCs from i.MX series
> and firstly introduced in i.MX25 is not one in one compatible with the
> watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> controlles don't have WICR (and pretimeout notification support) and
> WMCR registers. To get benefit from the more advanced watchdog device
> and to avoid operations over non-existing registers on legacy SoCs add
> fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
> watchdog controllers.
Maybe also update Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt?
In a separate patch.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Masahiro Yamada @ 2016-09-26 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474368275.4030.45.camel@pengutronix.de>
Hi Philipp,
2016-09-20 19:44 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
>> Hi Philipp,
>>
>>
>> 2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> > Hi Masahiro,
>> >
>> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>> >>
>> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> ---
>> >>
>> >> Philipp,
>> >>
>> >> IIRC, you mentioned that you were planning to consolidate the double
>> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>> >>
>> >> I have not seen it in the ML, so I am sending this.
>> >>
>> >> Please let me know if you have some updates.
>> >
>> > I had started to doodle a bit, see
>> >
>> > git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
>> >
>> > but I haven't found time for cleanup and testing.
>>
>>
>> OK, I will merge this patch for now.
>>
>>
>>
>> BTW, I did not understand some of your commits under way.
>>
>>
>> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
>> Author: Philipp Zabel <p.zabel@pengutronix.de>
>> Date: Tue Aug 9 11:18:51 2016 +0200
>>
>> dmaengine: sunx6i: do not depend on reset controller framework
>>
>> The reset controller framework provides inline function stubs if
>> disabled.
>>
>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>>
>>
>>
>>
>>
>> As far as I see from drivers/dma/sun6i-dma.c,
>> the reset control is mandatory for this driver.
>>
>> Why are you removing the dependency?
>>
>>
>> Don't you care if it works on run-time
>> as long as it can build?
>
> I have not thought about this too hard, it's just there because the
> reset framework is not a build dependency (anymore). Some patches were
> necessary to remove dependency loops, but I think this one could just be
> dropped.
I have not taken a close look at it, but
if "dependency loops" is the reason for the change,
please mention it in the git-log.
I do not think we should remove the "depends on"
only for the reason "inline function stubs are already provided".
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RFC PATCH 00/11] pci: support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2016-09-26 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6722152.QTF992tLpW@wuerfel>
Hi Arnd,
On Thursday 22 September 2016 07:04 PM, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
>> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
>>> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I wrote:
>>> I've added the drivers/ntb maintainers to Cc, given that there is
>>> a certain degree of overlap between your work and the existing
>>> code, I think they should be part of the discussion.
>>>
>>>> Known Limitation:
>>>> *) Does not support multi-function devices
>>>
>>> If I understand it right, this was a problem for USB and adding
>>> it later made it somewhat inconsistent. Maybe we can at least
>>> try to come up with an idea of how multi-function devices
>>> could be handled even if we don't implement it until someone
>>> actually needs it.
>>
>> Actually IMO multi-function device in PCI should be much simpler than it is for
>> USB. In the case of USB, all the functions in a multi-function device will
>> share the same *usb configuration* . (USB device can have multiple
>> configuration but only one can be enabled at a time). A multi-function USB
>> device will still have a single vendor-id/product-id/class... So I think a
>> separate library (composite.c) in USB makes sense.
>
> Ok, makes sense.
>
>> But in the case of PCI, every function can be treated independently since all
>> the functions have it's own 4KB configuration space. Each function can be
>> configured independently. Each can have it's own vendor-id/product-id/class..
>> I'm not sure if we'll need a separate library for PCI like we have for USB.
>
> I think it depends on whether we want to add the software multi-function
> support you mention.
>
>> Now the restriction for not allowing multi-function device is because of the
>> following structure definition.
>>
>> struct pci_epc {
>> ..
>> struct pci_epf *epf;
>> ..
>> };
>>
>> EPC has a single reference to EPF and it is used *only* to notify the function
>> driver when the link is up. (If this can be changed to use notification
>> mechanism, multi-function devices can be supported here)
>>
>> One more place where this restriction arises is in designware driver
>>
>> struct dw_pcie_ep {
>> ..
>> u8 bar_to_atu[6];
>> ..
>> };
>>
>> We use single ATU window to configure a BAR (in BAR). If there are multiple
>> functions, then this should also be modified since each function has 6 BARs.
>>
>> This can be fixed without much effort unless some other issue props up.
>
> Ok.
>
>>>
>>> Is your hardware able to make the PCIe endpoint look like
>>> a device with multiple PCI functions, or would one have to
>>> do this in software inside of a single PCI function if we
>>> ever need it?
>>
>> The hardware I have doesn't support multiple PCI functions (like having a
>> separate configuration space for each function). It has a dedicated space for
>> configuration space supporting only one function. [Section 24.9.7.3.2
>> PCIe_SS_EP_CFG_DBICS Register Description in [1]].
>>
>> yeah, it has to be done in software (but that won't be multi-function device in
>> PCI terms).
>>
>> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
>
> Ok, so in theory there can be other hardware (and quite likely is)
> that supports multiple functions, and we can extend the framework
> to support them without major obstacles, but your hardware doesn't,
> so you kept it simple with one hardcoded function, right?
right, PCIe can have upto 8 functions. So the issues with the current framework
has to be fixed. I don't expect major obstacles with this as of now.
>
> Seems completely reasonable to me.
>
>>>> TODO:
>>>> *) access buffers in RC
>>>> *) raise MSI interrupts
>>>> *) Enable user space control for the RC side PCI driver
>>>
>>> The user space control would end up just being one of several
>>> gadget drivers, right? E.g. gadget drivers for standard hardware
>>> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
>>> drivers while a user space driver can be used for things that
>>> are more unusual and that don't need to interface to another
>>> part of the kernel?
>>
>> Actually I didn't mean that. It was more with respect to the host side PCI test
>> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
>> itself. I wanted to change this so that the user controls which tests to run.
>> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
>> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
>> to perform various PCI tests.
>
> Ok, I see. So what I described above would be yet another function
> driver that can be implemented, but so far, you have not planned
> to do that because there was not need, right?
right. I felt pci_endpoint_test is the generic function that would be of
interest to all the vendors. Any new function can be added by taking
pci_endpoint_test as a reference.
The simple usecase I plan to work on after completing the framework is to have
a camera sensor in one board and display in another board (the boards connected
using PCIe) and the display showing the the camera capture.
>
>>>
>>>> *) Adapt all other users of designware to use the new design (only
>>>> dra7xx has been adapted)
>>>
>>> I don't fully understand this part. Does every designware based
>>> driver need modifications, or are the changes to the
>>> generic parts of the designware driver enough to make it
>>> work for the simpler platforms?
>>
>> I have changed the core designware driver structures (like previously the
>> platform drivers will only use pcie_port, but now I introduced struct dw_pcie
>> to support both host and endpoint). This will break (compilation failure) all
>> the designware based drivers (except dra7xx). All these drivers should be
>> adapted to the new change (even if they work only in host mode these has to be
>> adapted).
>
> Ah, so we have to do two separate modifications to each designware driver:
>
> a) make it work with your patch (mandatory)
> b) make it support endpoint mode (optional)
yes.
>
>>>> HOW TO:
>>>>
>>>> ON THE EP SIDE:
>>>> ***************
>>>>
>>>> /* EP function is configured using configfs */
>>>> # mount -t configfs none /sys/kernel/config
>>>>
>>>> /* PCI EP core layer creates "pci_ep" entry in configfs */
>>>> # cd /sys/kernel/config/pci_ep/
>>>>
>>>> /*
>>>> * This is the 1st step in creating an endpoint function. This
>>>> * creates the endpoint function device *instance*. The string
>>>> * before the .<num> suffix will identify the driver this
>>>> * EP function will bind to.
>>>> * Just pci_epf_test is also valid. The .<num> suffix is used
>>>> * if there are multiple PCI controllers and all of them wants
>>>> * to use the same function.
>>>> */
>>>> # mkdir pci_epf_test.0
>>>
>>> I haven't used USB gadgets, but I assume this is modeled around
>>> the same interface. If there are notable differences, please mention
>>> what they are. Otherwise the general concept seems rather nice to me.
>>
>> Yeah, both USB gadget and PCI endpoint use configfs interface but the semantics
>> are quite different.
>>
>> Every directory in *usb_gadget* corresponds to a gadget device, and the gadget
>> device has a functions sub-directory which has the USB functions. And these
>> directories have fields or attributes specific to USB.
>>
>> But in the case of PCI, every directory in *pci_ep* corresponds to a PCI
>> function and it has fields or attributes specific to PCI function.
>
> Ok, I see.
>
>> The main reason for using configfs for PCI endpoint is to give the users to
>> control "which function has to be bound to which controller". The same concept
>> is used for USB gadget as well but there it is "which gadget device has to be
>> bound to which controller".
>
> We should still find out whether it's important that you can have
> a single PCI function with a software multi-function support of some
> sort. We'd still be limited to six BARs in total, and would also need
> something to identify those sub-functions, so implementing that might
> get quite hairy.
>
> Possibly this could be done at a higher level, e.g. by implementing
> a PCI-virtio multiplexer that can host multiple virtio based devices
> inside of a single PCI function. If we think that would be a good idea,
> we should make sure the configfs interface is extensible enough to
> handle that.
Okay. So here the main function (actual PCI function) *can* perform the work of
virtio muliplexer if the platform wants to support sub-functions or it can be a
normal PCI function. right?
>
> One use case I have in mind for this is to have a PCI function that
> can use virtio to provide rootfs (virtio-blk or 9pfs), network
> and console to the system that implements the PCI function (note
> that this is the opposite direction of what almost everyone else
> uses PCI devices for).
Do you mean the virtio should actually be in the host side? Even here the
system that implements PCI function should have multiple functions right? (one
for network, other for console etc..). So there should be a virtio multiplexer
both in the host side and in the device side?
>
>>> Let's talk (high-level) about the DT binding. I see that the way
>>> you have done it here, one will need to have a different .dtb file
>>> for a machine depending on whether the PCIe is used in host or
>>> endpoint mode. The advantage of this way is that it's a much
>>> cleaner binding (PCIe host bindings are a mess, and adding more
>>> options to it will only make it worse), the downside is that
>>> you can't decide at runtime what you want to use it for. E.g.
>>> connecting two identical machines over PCIe requires deciding
>>> in the bootloader which one is the endpoint, or using DT
>>> overlays, which may be awkward for some users. Is this a realistic
>>> use case, or do you expect that all machines will only ever be
>>> used in one of the two ways?
>>
>> It would definitely be nice to select the mode at runtime. Even for this patch
>> series, I added a temporary dtsi patch to configure the pci controller in EP
>> mode (which can't be merged since the same controller is also used to test RC).
>
> I think it should be possible to have two bindings that define a
> distinct set of properties, and have one node that is marked
> as "compatible" with both of them in order to let the OS choose
> one or the other mode.
hmm.. okay.
Thanks
Kishon
^ permalink raw reply
* [PATCH] tty/serial: atmel: fix fractional baud rate computation
From: Uwe Kleine-König @ 2016-09-26 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921104414.16241-1-nicolas.ferre@atmel.com>
Hello,
On Wed, Sep 21, 2016 at 12:44:14PM +0200, Nicolas Ferre wrote:
> From: Alexey Starikovskiy <aystarik@gmail.com>
>
> The problem with previous code was it rounded values in wrong
> place and produced wrong baud rate in some cases.
>
> Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
> [nicolas.ferre at atmel.com: port to newer kernel and add commit log]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I first thought this patch results in not always picking the optimal
divider in some cases. But given the right error function (i.e.
error(r) = abs(1/r_target - 1/r_actual) which minimizes the error in the
time domain and so guarantees the maximal count of matched samples) it
can be proved to result in the right values (assuming no overflow etc.).
As writing formulas in email is cumbersome, see the attachment for a
prove.
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baudrate.pdf
Type: application/pdf
Size: 69704 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160926/02579e68/attachment-0001.pdf>
^ permalink raw reply
* [PATCH v3] arm: dts: zynq: Add MicroZed board support
From: Michal Simek @ 2016-09-26 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474624113-22825-1-git-send-email-jagan@amarulasolutions.com>
On 23.9.2016 11:48, Jagan Teki wrote:
> From: Jagan Teki <jteki@openedev.com>
>
> Added basic dts support for MicroZed board.
>
> - UART
> - SDHCI
> - Ethernet
>
> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Jagan Teki <jteki@openedev.com>
> ---
> Changes for v3:
> - Add Xilinx copyright
> Changes for v2:
> - Add SDHCI
> - Add Ethernet
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/zynq-microzed.dts | 96 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 97 insertions(+)
> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..4d7b858 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
> wm8750-apc8750.dtb \
> wm8850-w70v2.dtb
> dtb-$(CONFIG_ARCH_ZYNQ) += \
> + zynq-microzed.dtb \
> zynq-parallella.dtb \
> zynq-zc702.dtb \
> zynq-zc706.dtb \
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
> new file mode 100644
> index 0000000..b9376a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2016 Jagan Teki <jteki@openedev.com>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MicroZED Development Board";
> + compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x40000000>;
> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <33333333>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb0_default>;
> +};
> +
> +&pinctrl0 {
> + pinctrl_usb0_default: usb0-default {
> + mux {
> + groups = "usb0_0_grp";
> + function = "usb0";
> + };
> +
> + conf {
> + groups = "usb0_0_grp";
> + slew-rate = <0>;
> + io-standard = <1>;
> + };
> +
> + conf-rx {
> + pins = "MIO29", "MIO31", "MIO36";
> + bias-high-impedance;
> + };
> +
> + conf-tx {
> + pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
> + "MIO35", "MIO37", "MIO38", "MIO39";
> + bias-disable;
> + };
> + };
> +};
>
Applied.
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 3/4] clk: imx31: fix rewritten input argument of mx31_clocks_init()
From: Uwe Kleine-König @ 2016-09-26 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-4-git-send-email-vz@mleia.com>
Hello,
On Mon, Sep 26, 2016 at 03:03:42AM +0300, Vladimir Zapolskiy wrote:
> Function mx31_clocks_init() is called during clock intialization on
> legacy boards with reference clock frequency passed as its input
> argument, this can be verified by examination of the function
> declaration found in arch/arm/mach-imx/common.h and actual function
> users which include that header file.
>
> Inside CCF driver the function ignores its input argument, by chance
> the used value in the function body is the same as input arguments on
> side of all callers.
>
> Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v7 0/8] power: add power sequence library
From: Peter Chen @ 2016-09-26 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-1-git-send-email-peter.chen@nxp.com>
On Tue, Sep 20, 2016 at 11:36:39AM +0800, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
>
> Changes for v7:
> - Create kinds of power sequence instance at postcore_initcall, and match
> the instance with node using compatible string, the beneit of this is
> the host driver doesn't need to consider which pwrseq instance needs
> to be used, and pwrseq core will match it, however, it eats some memories
> if less power sequence instances are used. [Patch 2/8]
> - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> use device_node for parameters at pwrseq_on. [Patch 2/8]
> - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> - Tested three pwrseq instances together using both specific compatible string and
> generic libraries.
>
Hi Vaibhav, would you please test if this series can support your case,
you can add one instance like pwrseq_compatible_sample? If you are busy
now, but think this series can satisfy your requirement, please ack it.
I will delete pwrseq_compatible_sample, and only submit the generic one
at next revision, you can add it later, thanks.
Peter
> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
> the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
> at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
> layer's at core's probe
>
> Joshua Clayton (2):
> ARM: dts: imx6qdl: Enable usb node children with <reg>
> ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
> binding-doc: power: pwrseq-generic: add binding doc for generic power
> sequence library
> power: add power sequence library
> binding-doc: usb: usb-device: add optional properties for power
> sequence
> usb: core: add power sequence handling for USB devices
> usb: chipidea: let chipidea core device of_node equal's glue layer
> device of_node
> ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
> .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++++++
> .../devicetree/bindings/usb/usb-device.txt | 10 +-
> MAINTAINERS | 9 +
> arch/arm/boot/dts/imx6q-evi.dts | 25 +--
> arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-
> arch/arm/boot/dts/imx6qdl.dtsi | 6 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 45 +++++
> drivers/power/pwrseq/Makefile | 3 +
> drivers/power/pwrseq/core.c | 190 +++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_compatible_sample.c | 178 +++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 177 +++++++++++++++++++
> drivers/usb/chipidea/core.c | 27 ++-
> drivers/usb/core/hub.c | 41 ++++-
> drivers/usb/core/hub.h | 1 +
> include/linux/power/pwrseq.h | 73 ++++++++
> 17 files changed, 820 insertions(+), 41 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_compatible_sample.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Uwe Kleine-König @ 2016-09-26 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-3-git-send-email-vz@mleia.com>
Hello Vladimir,
On Mon, Sep 26, 2016 at 03:39:21AM +0300, Vladimir Zapolskiy wrote:
> Watchdog device controller found on all modern SoCs from i.MX series
> and firstly introduced in i.MX25 is not one in one compatible with the
> watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> controlles don't have WICR (and pretimeout notification support) and
> WMCR registers. To get benefit from the more advanced watchdog device
> and to avoid operations over non-existing registers on legacy SoCs add
> fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
> watchdog controllers.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> arch/arm/boot/dts/imx35.dtsi | 3 ++-
> arch/arm/boot/dts/imx50.dtsi | 3 ++-
> arch/arm/boot/dts/imx51.dtsi | 6 ++++--
> arch/arm/boot/dts/imx53.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
> arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
> arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
> arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
> 11 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
> index 490b7b4..8fd4482 100644
> --- a/arch/arm/boot/dts/imx35.dtsi
> +++ b/arch/arm/boot/dts/imx35.dtsi
> @@ -284,7 +284,8 @@
> };
>
> wdog: wdog at 53fdc000 {
> - compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
> + compatible = "fsl,imx35-wdt", "fsl,imx25-wdt",
> + "fsl,imx21-wdt";
When this is used on an old kernel that doesn't know about fsl,imx25-wdt
this picks up the imx21 driver logic. As this is wrong I think you
should drop imx21-wdt here. Can one of the dt-people comfirm?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: imx31: move CCM device node to AIPS2 bus devices
From: Uwe Kleine-König @ 2016-09-26 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-3-git-send-email-vz@mleia.com>
Hello Vladimir,
On Mon, Sep 26, 2016 at 03:03:41AM +0300, Vladimir Zapolskiy wrote:
> i.MX31 Clock Control Module controller is found on AIPS2 bus, move it
> there from SPBA bus to avoid a conflict of device IO space mismatch.
>
> Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
out of interest: Which kind of machine do you work with? I assume this
isn't just a finger exercise with qemu?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Adrian Hunter @ 2016-09-26 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474818243-19207-1-git-send-email-weiyj.lk@gmail.com>
On 25/09/16 18:44, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
> symbol 'sdhci_arasan_reset' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index da8e40a..e263671 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -250,7 +250,7 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> -void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> {
> u8 ctrl;
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>
>
>
>
^ permalink raw reply
* [PATCH v3 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-26 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923183421.GA14864@rob-hp-laptop>
Hello,
On 09/23/2016 08:34 PM, Rob Herring wrote:
> On Tue, Sep 20, 2016 at 09:01:38AM +0200, C?dric Le Goater wrote:
>> From: Alistair Popple <alistair@popple.id.au>
>>
>> This patch adds a simple device driver to expose the iBT interface on
>> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
>> commonly used as BMCs (BaseBoard Management Controllers) and this
>> driver implements the BMC side of the BT interface.
>>
>> The BT (Block Transfer) interface is used to perform in-band IPMI
>> communication between a host and its BMC. Entire messages are buffered
>> before sending a notification to the other end, host or BMC, that
>> there is data to be read. Usually, the host emits requests and the BMC
>> responses but the specification provides a mean for the BMC to send
>> SMS Attention (BMC-to-Host attention or System Management Software
>> attention) messages.
>>
>> For this purpose, the driver introduces a specific ioctl on the
>> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
>> on the BMC to signal the host of such an event.
>>
>> The device name defaults to '/dev/ipmi-bt-host'
>>
>> Signed-off-by: Alistair Popple <alistair@popple.id.au>
>> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> [clg: - checkpatch fixes
>> - added a devicetree binding documentation
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>> ]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> [clg: - checkpatch --strict fixes
>> - removed the use of devm_iounmap, devm_kfree in cleanup paths
>> - introduced an atomic-t to limit opens to 1
>> - introduced a mutex to protect write/read operations]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>>
>> ---
>>
>> Changes since v2:
>>
>> - fixed checkpatch --strict issues
>> - cleanup'ed includes
>> - limit to one opener
>> - protect write/read operations with a mutex.
>> - removed the use of devm_iounmap, devm_kfree in cleanup paths
>>
>> Changes since v1:
>>
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>
>> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
>
> While similar, this is not the kernel directory structure. Just make
> this bindings/ipmi/
>
> With that,
>
> Acked-by: Rob Herring <robh@kernel.org>
OK. So I suppose we should be moving all IPMI documentation under
the same directory.
Corey,
If the move is okay for you, I can send the patch below.
Thanks,
C.
>From ca25f89b25209c260480cda5e5532d6bbe83ed43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
Date: Mon, 26 Sep 2016 08:45:15 +0200
Subject: [PATCH] dt-bindings: ipmi: move all documentation under
bindings/ipmi/
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
.../devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt | 0
Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt} | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt (100%)
rename Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt} (100%)
diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
rename to Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
diff --git a/Documentation/devicetree/bindings/ipmi.txt b/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
similarity index 100%
rename from Documentation/devicetree/bindings/ipmi.txt
rename to Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
--
2.7.4
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Felipe Balbi @ 2016-09-26 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923150323.GB13744@kroah.com>
Hi,
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Fri, Sep 23, 2016 at 04:20:45PM +0200, Nicolas Ferre wrote:
>> Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
>> > Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
>> >> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
>> >> atmel_usba_udc fails with:
>> >>
>> >> ------------[ cut here ]------------
>> >> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
>> >> ecm_do_notify+0x188/0x1a0
>> >> Modules linked in:
>> >> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
>> >> Hardware name: Atmel SAMA5
>> >> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
>> >> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
>> >> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
>> >> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
>> >> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
>> >> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
>> >> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
>> >> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
>> >> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
>> >> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
>> >> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
>> >> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
>> >> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
>> >> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
>> >> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
>> >> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
>> >> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
>> >> ---[ end trace e7cf9dcebf4815a6 ]---
>> >>
>> >> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
>> >> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>> >> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> >
>> > Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> >
>> > Felipe, Greg,
>> > It is clearly a regression and material for 4.8-fixes. But I do know
>> > that we are very late in the process :-(
>> > Please do what you can to make it progress before 4.8-final but I'm
>> > truly aware of the challenge.
>>
>> Any chance that we can have it (aka ping)?
>
> It's Felipe's area, not mine :)
Sorry, I had missed this one. Greg, seems like this would be the only
pending fix. Do you want it in a pull request or would you prefer to
just pick it up as a patch? Works either way for me. In case you decide
to pick it up as a patch:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
If you prefer to pick it up as a pull request, I already have the patch
in my 'fixes' branch, just need to tag it and send it to you.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160926/244552d8/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: pxa_cplds: honor probe deferral
From: Robert Jarzmik @ 2016-09-26 7:21 UTC (permalink / raw)
To: linux-arm-kernel
The method to acquire the input interrupt was working in a platform data
based board, but was failing in a device-tree one when the gpio
controller was probed after pxa_cplds.
Use platform_get_irq() to benefit from the probe deferral
mechanism. Moreover, as seen in dm9000.c development, platform_get_irq()
doesn't honor the irq type IO resource (ie. edge rising for example),
and it must be passed again at irq request in a not device-tree build,
hence the irq_get_trigger_type() call.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/pxa_cplds_irqs.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/pxa_cplds_irqs.c b/arch/arm/mach-pxa/pxa_cplds_irqs.c
index e362f865fcd2..941508585e34 100644
--- a/arch/arm/mach-pxa/pxa_cplds_irqs.c
+++ b/arch/arm/mach-pxa/pxa_cplds_irqs.c
@@ -120,13 +120,9 @@ static int cplds_probe(struct platform_device *pdev)
if (!fpga)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res) {
- fpga->irq = (unsigned int)res->start;
- irqflags = res->flags;
- }
- if (!fpga->irq)
- return -ENODEV;
+ fpga->irq = platform_get_irq(pdev, 0);
+ if (fpga->irq <= 0)
+ return fpga->irq;
base_irq = platform_get_irq(pdev, 1);
if (base_irq < 0)
@@ -142,6 +138,7 @@ static int cplds_probe(struct platform_device *pdev)
writel(fpga->irq_mask, fpga->base + FPGA_IRQ_MASK_EN);
writel(0, fpga->base + FPGA_IRQ_SET_CLR);
+ irqflags = irq_get_trigger_type(fpga->irq);
ret = devm_request_irq(&pdev->dev, fpga->irq, cplds_irq_handler,
irqflags, dev_name(&pdev->dev), fpga);
if (ret == -ENOSYS)
--
2.1.4
^ permalink raw reply related
* [PATCH] ARM: pxa: fix pxa25x interrupt init
From: Robert Jarzmik @ 2016-09-26 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In the device-tree case, the root interrupt controller cannot be
accessed through the 6th coprocessor, contrary to pxa27x and pxa3xx
architectures.
Fix it to behave as in non-devicetree builds.
Fixes: 32f17997c130 ("ARM: pxa: remove irq init from dt machines")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/pxa25x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 12b94357fbc1..c725baf119e1 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -156,7 +156,7 @@ static int __init __init
pxa25x_dt_init_irq(struct device_node *node, struct device_node *parent)
{
pxa_dt_irq_init(pxa25x_set_wake);
- set_handle_irq(ichp_handle_irq);
+ set_handle_irq(icip_handle_irq);
return 0;
}
--
2.1.4
^ permalink raw reply related
* [PATCH] ARM: dts: pxa: fix gpio0 and gpio1 interrupts
From: Robert Jarzmik @ 2016-09-26 7:22 UTC (permalink / raw)
To: linux-arm-kernel
Since gpio-pxa was redesigned to differenciate gpio0, gpio1 and the
gpio-mux interrupt as in the hardware IP, the device-tree description
should be amended so that interrupts from gpio0 and gpio1 can be mapped
to consumers.
This is especially true on lubbock and mainstone devices where gpio0 is
multiplexed on pxa_cplds for ethernet, sa1111, usb udc, and other
devices.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/boot/dts/pxa2xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index 3ff077ca4400..e4ebcde17837 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -54,8 +54,8 @@
reg = <0x40e00000 0x10000>;
gpio-controller;
#gpio-cells = <0x2>;
- interrupts = <10>;
- interrupt-names = "gpio_mux";
+ interrupts = <8>, <9>, <10>;
+ interrupt-names = "gpio0", "gpio1", "gpio_mux";
interrupt-controller;
#interrupt-cells = <0x2>;
ranges;
--
2.1.4
^ permalink raw reply related
* [PATCH -next] arm64: Kconfig: select OF/ACPI_NUMA under NUMA config
From: Kefeng Wang @ 2016-09-26 7:36 UTC (permalink / raw)
To: linux-arm-kernel
Move OF_NUMA select under NUMA config, and select ACPI_NUMA
when ACPI enabled.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm64/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3b4afbc..6ee8ceb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -100,7 +100,6 @@ config ARM64
select NO_BOOTMEM
select OF
select OF_EARLY_FLATTREE
- select OF_NUMA if NUMA && OF
select OF_RESERVED_MEM
select PCI_ECAM if ACPI
select POWER_RESET
@@ -578,6 +577,8 @@ config HOTPLUG_CPU
config NUMA
bool "Numa Memory Allocation and Scheduler Support"
depends on SMP
+ select ACPI_NUMA if ACPI
+ select OF_NUMA
help
Enable NUMA (Non Uniform Memory Access) support.
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
From: Heiko Stuebner @ 2016-09-26 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926035511.GG17336@vireshk-i7>
Am Montag, 26. September 2016, 09:25:11 CEST schrieb Viresh Kumar:
> On 12-09-16, 14:55, Stephen Boyd wrote:
> > On 08/29, Viresh Kumar wrote:
> > > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > > + struct cpufreq_frequency_table *table,
> > > > + int volt)
> > > > +{
> > > > + struct opp_table *opp_table;
> > > > + struct cpufreq_frequency_table *pos;
> > > > + struct dev_pm_opp *opp;
> > > > +
> > > > + if (!volt)
> > > > + return 0;
> > > > +
> > > > + rcu_read_lock();
> > > > +
> > > > + opp_table = _find_opp_table(cpu_dev);
> > > > + if (IS_ERR(opp_table)) {
> > > > + rcu_read_unlock();
> > > > + return PTR_ERR(opp_table);
> > > > + }
> > > > +
> > > > + cpufreq_for_each_valid_entry(pos, table) {
> > > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > > + true);
> > > > + if (IS_ERR(opp))
> > > > + continue;
> > > > +
> > > > + opp->u_volt += volt;
> > > > + opp->u_volt_min += volt;
> > > > + opp->u_volt_max += volt;
> > > > + }
> > > > +
> > > > + rcu_read_unlock();
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > I wouldn't prefer altering the opp tables from individual drivers at
> > > all. At the least, it should be done via some helpers exposed by the
> > > core.
> > >
> > > But before that I would like to hear from Stephen a bit as I recall he
> > > was also working on something similar.
> >
> > I had a patch to modify the voltage at runtime for the "current"
> > OPP. Now that we have regulator and clk control inside OPP that
> > became a little easier to do without having to do some notifier
> > from the OPP layer to the consumers. I haven't had time to revive
> > those patches though. Should we do that?
>
> Perhaps yes, we should have a common place for doing all that.
>
> > Does this need to modify
> > anything besides the OPP the device is currently running at?
>
> Finlye, can you please answer this ?
If I understand it correctly, depending on the leakage value stored in an
efuse, all opp voltages are reduced by a certain value. Right now the driver
does it in one go for the full opp table, but of course could also do it for
each new opp individually before it gets set.
^ permalink raw reply
* [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode
From: Po Liu @ 2016-09-26 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130620.GA1486@rob-hp-laptop>
Hi Rob,
> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Friday, September 23, 2016 9:06 PM
> To: Po Liu
> Cc: Shawn Guo; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Roy Zang; Arnd Bergmann; Marc Zyngier;
> Stuart Yoder; Leo Li; M.H. Lian; Murali Karicheri; Bjorn Helgaas;
> Mingkai Hu
> Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none
> MSI/MSI-X/INTx mode
>
> On Sun, Sep 18, 2016 at 03:37:27AM +0000, Po Liu wrote:
> > Hi Shawn,
> >
> >
> > > -----Original Message-----
> > > From: Shawn Guo [mailto:shawnguo at kernel.org]
> > > Sent: Sunday, September 18, 2016 8:52 AM
> > > To: Po Liu
> > > Cc: linux-pci at vger.kernel.org;
> > > linux-arm-kernel at lists.infradead.org;
> > > linux-kernel at vger.kernel.org; devicetree at vger.kernel.org; Roy Zang;
> > > Arnd Bergmann; Marc Zyngier; Stuart Yoder; Leo Li; M.H. Lian;
> > > Murali Karicheri; Bjorn Helgaas; Mingkai Hu
> > > Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with
> > > none MSI/MSI-X/INTx mode
> > >
> > > On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> > > > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC
> mode.
> > > > When chip support the aer interrupt with none MSI/MSI-X/INTx
> > > mode, > maybe there is interrupt line for aer pme etc. Search the
> > > interrupt > number in the fdt file. Then fixup the dev->irq with it.
> > > >
> > > > Signed-off-by: Po Liu <po.liu@nxp.com>
> > >
> > > Will the new kernel work with existing/old DTB? I'm trying to
> > > understand the dependency between driver and DTS changes.
> >
> > Yes, We've never use name 'intr' before. So we remove it is ok.
> > 'aer' is a dts name for researching it's true interrupt number by
> > kernel. This patch is first time to use name 'aer'. So it must be
> > compatible with existing/old DTB.
>
> Please explain why you are not breaking compatibility in the commit
> message. I asked for this on v2.
Sorry, I didn't really catch what your means. Do you mean I should add why I remove the 'intr'?
>
> > > > ---
> > > > changes for v5:
> > > > - Add clear 'aer' interrup-names description
> > > >
> > > > .../devicetree/bindings/pci/layerscape-pci.txt | 11 +++++---
> > > > drivers/pci/pcie/portdrv_core.c | 31
> > > +++++++++++++++++++---
> > > > 2 files changed, 35 insertions(+), 7 deletions(-) > > diff
> > > --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > index 41e9f55..101d0a7 100644
> > > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > @@ -18,8 +18,10 @@ Required properties:
> > > > - reg: base addresses and lengths of the PCIe controller > -
> > > interrupts: A list of interrupt outputs of the controller. Must
> > > contain an
> > > > entry for each entry in the interrupt-names property.
> > > > -- interrupt-names: Must include the following entries:
> > > > - "intr": The interrupt that is asserted for controller
> > > interrupts > +- interrupt-names: It may be include the following
> entries:
>
> "may be" is not okay. It should be "must" or explain when an interrupt
> would not be present. Really, differences in interrupts means you need
> different compatible strings.
How about changing "must" to "should" or "could" and also add when to add after "aer": to explain when to add it?
Thanks!
>
> Rob
>
> > > > + "aer": The interrupt that is asserted for aer interrupt > +
> > > "pme": The interrupt that is asserted for pme interrupt > + ......
^ permalink raw reply
* Re: [PATCH V5 2/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2016-09-26 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2add7cb9193b96211f5e5938cbfc6181c76e2591.1470739193.git.peter.senna@collabora.com>
Patch 1/4 is already on linux-next, but what about this one? Ping?
On Tuesday, August 9, 2016 18:41 CEST, Peter Senna Tschudin <peter.senna@collabora.com> wrote:
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> Cc: Martin Donnelly <martin.donnelly@ge.com>
> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> ---
> Unchanged from V4
>
> Changes from V3:
> - 2/4 instead of 3/5
>
> Unchanged from V2
>
> Changes from V1:
> - Replaced '_' by '-' in node names or compatible strings
> - Added missing @73 to the example
>
>
> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> new file mode 100644
> index 0000000..f05c3e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,37 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> + - compatible : should be "ge,b850v3-lvds-dp".
> + - reg : should contain the address used to ack the interrupts.
> + - interrupt-parent : phandle of the interrupt controller that services
> + interrupts to the device
> + - interrupts : one interrupt should be described here, as in
> + <0 IRQ_TYPE_LEVEL_HIGH>.
> + - edid-reg : should contain the address used to read edid information
> + - port : should describe the video signal connection between the host
> + and the bridge.
> +
> +Example:
> +
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <100000>;
> +
> + b850v3-lvds-dp-bridge at 73 {
> + compatible = "ge,b850v3-lvds-dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + edid-reg = <0x72>;
> +
> + port {
> + b850v3_dp_bridge_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
> --
> 2.5.5
>
^ permalink raw reply
* Re: [PATCH V5 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
From: Peter Senna Tschudin @ 2016-09-26 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37d177d89841be8ff8eec395e3267d1ebf0dfc54.1470739193.git.peter.senna@collabora.com>
Patch 1/4 is already on linux-next, but what about this one? Ping?
On Tuesday, August 9, 2016 18:41 CEST, Peter Senna Tschudin <peter.senna@collabora.com> wrote:
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> firmware made it complicated for this binding to comprise two device
> tree nodes, as the design goal is to configure both bridges based on
> the LVDS signal, which leave the driver powerless to control the video
> processing pipeline. The two bridges behaves as a single bridge, and
> the driver is only needed for telling the host about EDID / HPD, and
> for giving the host powers to ack interrupts. The video signal pipeline
> is as follows:
>
> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
>
> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> Cc: Martin Donnelly <martin.donnelly@ge.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> CC: David Airlie <airlied@linux.ie>
> CC: Thierry Reding <treding@nvidia.com>
> CC: Thierry Reding <thierry.reding@gmail.com>
> Reviewed-by: Enric Balletbo <enric.balletbo@collabora.com>
> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> ---
> Changes from V4:
> - Check the output of the first call to i2c_smbus_write_word_data() and return
> it's error code for failing gracefully on i2c issues
> - Renamed the i2c_driver.name from "ge,b850v3-lvds-dp" to "b850v3-lvds-dp" to
> remove the comma from the driver name
>
> Changes from V3:
> - 3/4 instead of 4/5
> - Tested on next-20160804
>
> Changes from V2:
> - Made it atomic to be applied on next-20160729 on top of Liu Ying changes
> that made imx-ldb atomic
>
> Changes from V1:
> - New commit message
> - Removed 3 empty entry points
> - Removed memory leak from ge_b850v3_lvds_dp_get_modes()
> - Added a lock for mode setting
> - Removed a few blank lines
> - Changed the order at Makefile and Kconfig
>
> MAINTAINERS | 8 +
> drivers/gpu/drm/bridge/Kconfig | 11 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 405 +++++++++++++++++++++++++++++
> 4 files changed, 425 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a306795..e8d106a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5142,6 +5142,14 @@ W: https://linuxtv.org
> S: Maintained
> F: drivers/media/radio/radio-gemtek*
>
> +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> +M: Peter Senna Tschudin <peter.senna@collabora.com>
> +M: Martin Donnelly <martin.donnelly@ge.com>
> +M: Martyn Welch <martyn.welch@collabora.co.uk>
> +S: Maintained
> +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> +
> GENERIC GPIO I2C DRIVER
> M: Haavard Skinnemoen <hskinnemoen@gmail.com>
> S: Supported
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e67..b4b70fb 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO
> Designware HDMI block. This is used in conjunction with
> the i.MX6 HDMI driver.
>
> +config DRM_GE_B850V3_LVDS_DP
> + tristate "GE B850v3 LVDS to DP++ display bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + ---help---
> + This is a driver for the display bridge of
> + GE B850v3 that convert dual channel LVDS
> + to DP++. This is used with the i.MX6 imx-ldb
> + driver.
> +
> config DRM_NXP_PTN3460
> tristate "NXP PTN3460 DP/LVDS bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index efdb07e..b9606f3 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> obj-$(CONFIG_DRM_SII902X) += sii902x.o
> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 0000000..81e9279
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,405 @@
> +/*
> + * Driver for GE B850v3 DP display bridge
> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> +
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> +
> + * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
> + * display bridge of the GE B850v3. There are two physical bridges on the video
> + * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). However
> + * the physical bridges are automatically configured by the input video signal,
> + * and the driver has no access to the video processing pipeline. The driver is
> + * only needed to read EDID from the STDP2690 and to handle HPD events from the
> + * STDP4028. The driver communicates with both bridges over i2c. The video
> + * signal pipeline is as follows:
> + *
> + * Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> + *
> + */
> +
> +#include <linux/gpio.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drmP.h>
> +
> +/*
> + * 220Mhz is a limitation of the host, as the bridge is capable of up to
> + * 330Mhz. See section 9.2.1.2.4 of the i.MX 6Dual/6Quad Applications
> + * Processor Reference Manual for more information about the 220Mhz limit.
> + * The imx-ldb driver will warn about clocks over 170Mhz, but it seem to work
> + * fine.
> + */
> +#define MAX_PIXEL_CLOCK 220000
> +
> +#define EDID_EXT_BLOCK_CNT 0x7E
> +
> +#define STDP4028_IRQ_OUT_CONF_REG 0x02
> +#define STDP4028_DPTX_IRQ_EN_REG 0x3C
> +#define STDP4028_DPTX_IRQ_STS_REG 0x3D
> +#define STDP4028_DPTX_STS_REG 0x3E
> +
> +#define STDP4028_DPTX_DP_IRQ_EN 0x1000
> +
> +#define STDP4028_DPTX_HOTPLUG_IRQ_EN 0x0400
> +#define STDP4028_DPTX_LINK_CH_IRQ_EN 0x2000
> +#define STDP4028_DPTX_IRQ_CONFIG \
> + (STDP4028_DPTX_LINK_CH_IRQ_EN | STDP4028_DPTX_HOTPLUG_IRQ_EN)
> +
> +#define STDP4028_DPTX_HOTPLUG_STS 0x0200
> +#define STDP4028_DPTX_LINK_STS 0x1000
> +#define STDP4028_CON_STATE_CONNECTED \
> + (STDP4028_DPTX_HOTPLUG_STS | STDP4028_DPTX_LINK_STS)
> +
> +#define STDP4028_DPTX_HOTPLUG_CH_STS 0x0400
> +#define STDP4028_DPTX_LINK_CH_STS 0x2000
> +#define STDP4028_DPTX_IRQ_CLEAR \
> + (STDP4028_DPTX_LINK_CH_STS | STDP4028_DPTX_HOTPLUG_CH_STS)
> +
> +struct ge_b850v3_lvds_dp {
> + struct drm_connector connector;
> + struct drm_bridge bridge;
> + struct i2c_client *ge_b850v3_lvds_dp_i2c;
> + struct i2c_client *edid_i2c;
> + struct edid *edid;
> + struct mutex lock;
> +};
> +
> +static inline struct ge_b850v3_lvds_dp *
> + bridge_to_ge_b850v3_lvds_dp(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct ge_b850v3_lvds_dp, bridge);
> +}
> +
> +static inline struct ge_b850v3_lvds_dp *
> + connector_to_ge_b850v3_lvds_dp(struct drm_connector *connector)
> +{
> + return container_of(connector, struct ge_b850v3_lvds_dp, connector);
> +}
> +
> +u8 *stdp2690_get_edid(struct i2c_client *client)
> +{
> + struct i2c_adapter *adapter = client->adapter;
> + unsigned char start = 0x00;
> + unsigned int total_size;
> + u8 *block = kmalloc(EDID_LENGTH, GFP_KERNEL);
> +
> + struct i2c_msg msgs[] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = &start,
> + }, {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = EDID_LENGTH,
> + .buf = block,
> + }
> + };
> +
> + if (!block)
> + return NULL;
> +
> + if (i2c_transfer(adapter, msgs, 2) != 2) {
> + DRM_ERROR("Unable to read EDID.\n");
> + goto err;
> + }
> +
> + if (!drm_edid_block_valid(block, 0, false, NULL)) {
> + DRM_ERROR("Invalid EDID block\n");
> + goto err;
> + }
> +
> + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
> + if (total_size > EDID_LENGTH) {
> + kfree(block);
> + block = kmalloc(total_size, GFP_KERNEL);
> + if (!block)
> + return NULL;
> +
> + /* Yes, read the entire buffer, and do not skip the first
> + * EDID_LENGTH bytes.
> + */
> + start = 0x00;
> + msgs[1].len = total_size;
> + msgs[1].buf = block;
> +
> + if (i2c_transfer(adapter, msgs, 2) != 2) {
> + DRM_ERROR("Unable to read EDID extension blocks.\n");
> + goto err;
> + }
> + }
> +
> + return block;
> +
> +err:
> + kfree(block);
> + return NULL;
> +}
> +
> +static int ge_b850v3_lvds_dp_get_modes(struct drm_connector *connector)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge;
> + struct i2c_client *client;
> + int num_modes = 0;
> +
> + ptn_bridge = connector_to_ge_b850v3_lvds_dp(connector);
> + client = ptn_bridge->edid_i2c;
> +
> + mutex_lock(&ptn_bridge->lock);
> +
> + kfree(ptn_bridge->edid);
> + ptn_bridge->edid = (struct edid *) stdp2690_get_edid(client);
> +
> + if (ptn_bridge->edid) {
> + drm_mode_connector_update_edid_property(connector,
> + ptn_bridge->edid);
> + num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
> + }
> +
> + mutex_unlock(&ptn_bridge->lock);
> +
> + return num_modes;
> +}
> +
> +
> +static enum drm_mode_status ge_b850v3_lvds_dp_mode_valid(
> + struct drm_connector *connector, struct drm_display_mode *mode)
> +{
> + if (mode->clock > MAX_PIXEL_CLOCK) {
> + DRM_INFO("The pixel clock for the mode %s is too high, and not supported.",
> + mode->name);
> + return MODE_CLOCK_HIGH;
> + }
> +
> + return MODE_OK;
> +}
> +
> +static const struct
> +drm_connector_helper_funcs ge_b850v3_lvds_dp_connector_helper_funcs = {
> + .get_modes = ge_b850v3_lvds_dp_get_modes,
> + .mode_valid = ge_b850v3_lvds_dp_mode_valid,
> +};
> +
> +static enum drm_connector_status ge_b850v3_lvds_dp_detect(
> + struct drm_connector *connector, bool force)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge =
> + connector_to_ge_b850v3_lvds_dp(connector);
> + struct i2c_client *ge_b850v3_lvds_dp_i2c =
> + ptn_bridge->ge_b850v3_lvds_dp_i2c;
> + s32 link_state;
> +
> + link_state = i2c_smbus_read_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_STS_REG);
> +
> + if (link_state == STDP4028_CON_STATE_CONNECTED)
> + return connector_status_connected;
> +
> + if (link_state == 0)
> + return connector_status_disconnected;
> +
> + return connector_status_unknown;
> +}
> +
> +static const struct drm_connector_funcs ge_b850v3_lvds_dp_connector_funcs = {
> + .dpms = drm_atomic_helper_connector_dpms,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .detect = ge_b850v3_lvds_dp_detect,
> + .destroy = drm_connector_cleanup,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static irqreturn_t ge_b850v3_lvds_dp_irq_handler(int irq, void *dev_id)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge = dev_id;
> + struct i2c_client *ge_b850v3_lvds_dp_i2c
> + = ptn_bridge->ge_b850v3_lvds_dp_i2c;
> +
> + mutex_lock(&ptn_bridge->lock);
> +
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_STS_REG, STDP4028_DPTX_IRQ_CLEAR);
> +
> + mutex_unlock(&ptn_bridge->lock);
> +
> + if (ptn_bridge->connector.dev)
> + drm_kms_helper_hotplug_event(ptn_bridge->connector.dev);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ge_b850v3_lvds_dp_attach(struct drm_bridge *bridge)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge
> + = bridge_to_ge_b850v3_lvds_dp(bridge);
> + struct drm_connector *connector = &ptn_bridge->connector;
> + struct i2c_client *ge_b850v3_lvds_dp_i2c
> + = ptn_bridge->ge_b850v3_lvds_dp_i2c;
> + int ret;
> +
> + if (!bridge->encoder) {
> + DRM_ERROR("Parent encoder object not found");
> + return -ENODEV;
> + }
> +
> + connector->polled = DRM_CONNECTOR_POLL_HPD;
> +
> + drm_connector_helper_add(connector,
> + &ge_b850v3_lvds_dp_connector_helper_funcs);
> +
> + ret = drm_connector_init(bridge->dev, connector,
> + &ge_b850v3_lvds_dp_connector_funcs,
> + DRM_MODE_CONNECTOR_DisplayPort);
> + if (ret) {
> + DRM_ERROR("Failed to initialize connector with drm\n");
> + return ret;
> + }
> +
> + drm_connector_register(connector);
> + ret = drm_mode_connector_attach_encoder(connector, bridge->encoder);
> + if (ret)
> + return ret;
> +
> + drm_bridge_enable(bridge);
> + if (ge_b850v3_lvds_dp_i2c->irq) {
> + drm_helper_hpd_irq_event(connector->dev);
> +
> + ret = devm_request_threaded_irq(&ge_b850v3_lvds_dp_i2c->dev,
> + ge_b850v3_lvds_dp_i2c->irq, NULL,
> + ge_b850v3_lvds_dp_irq_handler,
> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + "ge-b850v3-lvds-dp", ptn_bridge);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs ge_b850v3_lvds_dp_funcs = {
> + .attach = ge_b850v3_lvds_dp_attach,
> +};
> +
> +static int ge_b850v3_lvds_dp_probe(struct i2c_client *ge_b850v3_lvds_dp_i2c,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &ge_b850v3_lvds_dp_i2c->dev;
> + struct ge_b850v3_lvds_dp *ptn_bridge;
> + int ret;
> + u32 edid_i2c_reg;
> +
> + ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
> + if (!ptn_bridge)
> + return -ENOMEM;
> +
> + mutex_init(&ptn_bridge->lock);
> +
> + ptn_bridge->ge_b850v3_lvds_dp_i2c = ge_b850v3_lvds_dp_i2c;
> + ptn_bridge->bridge.driver_private = ptn_bridge;
> + i2c_set_clientdata(ge_b850v3_lvds_dp_i2c, ptn_bridge);
> +
> + ret = of_property_read_u32(dev->of_node, "edid-reg", &edid_i2c_reg);
> + if (ret) {
> + dev_err(dev, "edid-reg not specified, aborting...\n");
> + return -ENODEV;
> + }
> +
> + ptn_bridge->edid_i2c = devm_kzalloc(dev,
> + sizeof(struct i2c_client), GFP_KERNEL);
> +
> + if (!ptn_bridge->edid_i2c)
> + return -ENOMEM;
> +
> + memcpy(ptn_bridge->edid_i2c, ge_b850v3_lvds_dp_i2c,
> + sizeof(struct i2c_client));
> +
> + ptn_bridge->edid_i2c->addr = (unsigned short) edid_i2c_reg;
> +
> + /*
> + * Configures the bridge to re-enable interrupts after each ack. As
> + * this is the first communication with the chip, fail on error.
> + */
> + ret = i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_IRQ_OUT_CONF_REG, STDP4028_DPTX_DP_IRQ_EN);
> + if (ret) {
> + dev_err(dev, "i2c communication failed, aborting...\n");
> + return ret;
> + }
> +
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_EN_REG, STDP4028_DPTX_IRQ_CONFIG);
> +
> + /* Clear pending interrupts since power up. */
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_STS_REG, STDP4028_DPTX_IRQ_CLEAR);
> +
> + ptn_bridge->bridge.funcs = &ge_b850v3_lvds_dp_funcs;
> + ptn_bridge->bridge.of_node = dev->of_node;
> + ret = drm_bridge_add(&ptn_bridge->bridge);
> + if (ret) {
> + DRM_ERROR("Failed to add bridge\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ge_b850v3_lvds_dp_remove(struct i2c_client *ge_b850v3_lvds_dp_i2c)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge =
> + i2c_get_clientdata(ge_b850v3_lvds_dp_i2c);
> +
> + drm_bridge_remove(&ptn_bridge->bridge);
> +
> + kfree(ptn_bridge->edid);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id ge_b850v3_lvds_dp_i2c_table[] = {
> + {"b850v3-lvds-dp", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ge_b850v3_lvds_dp_i2c_table);
> +
> +static const struct of_device_id ge_b850v3_lvds_dp_match[] = {
> + { .compatible = "ge,b850v3-lvds-dp" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ge_b850v3_lvds_dp_match);
> +
> +static struct i2c_driver ge_b850v3_lvds_dp_driver = {
> + .id_table = ge_b850v3_lvds_dp_i2c_table,
> + .probe = ge_b850v3_lvds_dp_probe,
> + .remove = ge_b850v3_lvds_dp_remove,
> + .driver = {
> + .name = "b850v3-lvds-dp",
> + .of_match_table = ge_b850v3_lvds_dp_match,
> + },
> +};
> +module_i2c_driver(ge_b850v3_lvds_dp_driver);
> +
> +MODULE_AUTHOR("Peter Senna Tschudin <peter.senna@collabora.com>");
> +MODULE_AUTHOR("Martyn Welch <martyn.welch@collabora.co.uk>");
> +MODULE_DESCRIPTION("GE LVDS to DP++ display bridge)");
> +MODULE_LICENSE("GPL v2");
> --
> 2.5.5
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox