Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
On 09/25/2017 05:45 PM, Dmitry Osipenko wrote: > On 26.09.2017 02:01, Stephen Warren wrote: >> On 09/25/2017 04:15 PM, Dmitry Osipenko wrote: >>> Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of >>> video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports >>> decoding of CAVLC H.264 only. >> >> Note: I don't know anything much about video decoding on Tegra (just NV >> desktop >> GPUs, and that was a while ago), but I had a couple small comments on the DT >> binding: >> >>> diff --git >>> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt >>> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt >> >>> +NVIDIA Tegra Video Decoder Engine >>> + >>> +Required properties: >>> +- compatible : "nvidia,tegra20-vde" >>> +- reg : Must contain 2 register ranges: registers and IRAM area. >>> +- reg-names : Must include the following entries: >>> + - regs >>> + - iram >> >> I think the IRAM region needs more explanation: What is the region used for >> and >> by what? Can it be moved, and if so does the move need to be co-ordinated >> with >> any other piece of SW? > > IRAM region is used by Video Decoder HW for internal use and some of decoding > parameters are supplied via IRAM, like frames order list. AFAIK IRAM addresses > are hardwired in HW and aren't movable, it is not 100% but I'm pretty sure. > Should it be explained in the binding? I think this should be briefly mentioned, yes. Otherwise at least people who don't know the VDE HW well (like me) will wonder why on earth VDE interacts with IRAM at all. I would have assumed all parameters were supplied via registers or via descriptors in DRAM. Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
On 09/25/2017 04:15 PM, Dmitry Osipenko wrote: Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports decoding of CAVLC H.264 only. Note: I don't know anything much about video decoding on Tegra (just NV desktop GPUs, and that was a while ago), but I had a couple small comments on the DT binding: diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt +NVIDIA Tegra Video Decoder Engine + +Required properties: +- compatible : "nvidia,tegra20-vde" +- reg : Must contain 2 register ranges: registers and IRAM area. +- reg-names : Must include the following entries: + - regs + - iram I think the IRAM region needs more explanation: What is the region used for and by what? Can it be moved, and if so does the move need to be co-ordinated with any other piece of SW? +- clocks : Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. +- resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names : Must include the following entries: + - vde Let's require a clock-names property too. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: outreachy
On 03/09/2017 01:51 PM, Scott Branden wrote: Hi Julia, On 17-03-09 12:36 PM, Julia Lawall wrote: Hello, I discussed the issue of outreachy patches for bcm with Greg, and we are not convinced that not having the patches CCd to you is such a good idea. While we don't want to spam you with noise, some of the applicants are starting to make more significant changes that it could be useful for you to be aware of. Could we try a compromise where you are not CCd on whitespace patches, but you are CCd on patches that actually modify the code? > All I'm asking is you work through your outreachy patches internal first to get rid of the most basic mistakes and email traffic it is geerating. Once that learning process is through then they can be sent out like any other patches to the kernel mailing lists and maintainers. +1 from me too; I find these patches rather high volume and had to add a filter to keep them out of my primary inbox. I don't know what process is in place, but I would suggest: 1) Senders send everything to the outreachy list, where they are reviewed for basic issues, like learning to use git send-email, learning checkpatch, etc. In this case, only send the patch to the outreachy mailing list and nowhere else. 2) Once a patch has passed review there, then send the patch to the regular kernel mailing list just like any other patch; follow the output of get_maintainers.pl. We have something like (1) inside NVIDIA for new contributors and pre-upstreaming IP review. It helps all the newcomers, but without requiring anyone involved in (2) to change behaviour. The process I suggest is very much inline with the typically suggested "asking questions" process: (1) read docs yourself (2) ask local contacts for help, (3) start asking wider audiences for help. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 4/4] dt: paz00: define nvec as child of i2c bus
On 07/20/2015 02:35 PM, Andrey Danin wrote:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
+ nvec: nvec@45 {
+ compatible = "nvidia,nvec-slave";
+ reg = <0x45>;
I think you need to or in I2C_OWN_SLAVE_ADDRESS from
here?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/4] staging/nvec: reimplement on top of tegra i2c driver
On 07/20/2015 02:35 PM, Andrey Danin wrote: Remove i2c controller related code and use tegra i2c driver in slave mode. Update nvec documentation. diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt I would expect this patch to add a new binding file nvidia,nvec-slave.txt so that the filename continues to match the compatible value it documents. This patch introduces a new binding for the NVEC slave as opposed to modifying the existing binding. +- compatible : should be "nvidia,nvec-slave". +- reg: the i2c address of the slave controller I think "the I2C address to respond to" would be clearer? You might also mention that this needs to include flags from . ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Warning that occured while compiling the nvec in 3.19.0-rc5+ is fixed
On Sat, Jan 31, 2015 at 05:24:42PM +0530, varsharamt wrote: The task was to fix a warning which was shown while compiling a driver called NVEC. I wrote a brief description about how to enable support for a nVidya complaint embedded controller. Please note that NVIDIA is spelled/capitalized as NVIDIA. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Move DWC2 driver out of staging
On 02/03/2014 01:51 PM, Paul Zimmerman wrote: ... > Stephen, Andre, > > Can you test the attached patch, please? It works for my on the Synopsys > PCIe-based FPGA board. Unfortunately my RPI board is currently broken, > so I am unable to test it there to verify it actually fixes the problem > you are seeing. > > The dwc2 driver doesn't use the usb_device toggle bits anywhere else, > so the quickest fix is to just remove the problematic code from > _dwc2_hcd_endpoint_reset(). > > If you give me your tested-bys, I will submit this as a proper patch > to Greg. I've tested a basically equivalent patch (link below), so I feel comfortable saying: Tested-by: Stephen Warren https://github.com/swarren/linux-rpi/commit/f7b9c896153cc0501acecb58053db978ec00a5bf > @@ -2579,9 +2579,11 @@ static void _dwc2_hcd_endpoint_reset(struct usb_hcd > *hcd, > > spin_lock_irqsave(&hsotg->lock, flags); > > +#if 0 > usb_settoggle(udev, epnum, is_out, 0); > if (is_control) > usb_settoggle(udev, epnum, !is_out, 0); > +#endif > dwc2_hcd_endpoint_reset(hsotg, ep); > > spin_unlock_irqrestore(&hsotg->lock, flags); ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Move DWC2 driver out of staging
On 02/01/2014 03:00 AM, Andre Heider wrote: > On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote: >> On 01/31/2014 11:12 AM, Andre Heider wrote: >>> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote: >>>> The DWC2 driver should now be in good enough shape to move out of >>>> staging. I have stress tested it overnight on RPI running mass >>>> storage and Ethernet transfers in parallel, and for several days >>>> on our proprietary PCI-based platform. >> ... >>> this looks just fine, but for whatever reason it breaks sdhci on my rpi. >>> With today's Linus' master the dwc2 controller seems to initialize fine, >>> but I get this upon boot: >>> >>> [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12 >>> [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12 ... >> This is due to the following code: ... >> What ends up happening, simply due to memory allocation order, is that >> the memory writes inside usb_settoggle() end up setting the SDHCI struct >> platform_device's num_resources to 0, so that it's call to >> platform_get_resource() fails. >> >> With the DWC2 move patch reverted, some other random piece of memory is >> being corrupted, which just happens not to cause any visible problem. >> Likely it's some other struct platform_device that's already had its >> resources read by the time DWC2 probes and corrupts them. >> >> (Yes, this was hard to find!) > > Nice work, but how did you pinpoint this? Am I missing some option/tool > or did I just not stare for long enough? Well, there was a clear place where an issue was present; the resource lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs into that function to dump out the data platform_get_resource() used. This clearly pointed at num_resources==0 being the problem. Next, I dumped the same data from the code in drivers/of that sets it up, and it was OK there, so I knew it was getting over-written somewhere. I then basically added hundreds of calls to the same data dumping function throughout kernel functions like really_probe() to track down the location of the problem. Luckily, the behaviour was stable, so I wasn't chasing a race/timing condition. Eventually I narrowed the window to the few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would have been much harder if it was e.g. the USB HW DMAing to memory that caused the corruption, so I was lucky:-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Move DWC2 driver out of staging
On 01/31/2014 11:12 AM, Andre Heider wrote:
> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
>> The DWC2 driver should now be in good enough shape to move out of
>> staging. I have stress tested it overnight on RPI running mass
>> storage and Ethernet transfers in parallel, and for several days
>> on our proprietary PCI-based platform.
...
> this looks just fine, but for whatever reason it breaks sdhci on my rpi.
> With today's Linus' master the dwc2 controller seems to initialize fine,
> but I get this upon boot:
>
> [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
> [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12
>
> That is:
>
> struct sdhci_host *sdhci_pltfm_init(struct platform_device
> *pdev,
> const struct
> sdhci_pltfm_data *pdata,
> size_t priv_size)
> {
> ...
>
> iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!iomem) {
> ret = -ENOMEM;
> goto err;
> }
This is due to the following code:
static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd,
struct usb_host_endpoint *ep)
{
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
...
struct usb_device *udev;
...
udev = to_usb_device(hsotg->dev);
...
usb_settoggle(udev, epnum, is_out, 0);
if (is_control)
usb_settoggle(udev, epnum, !is_out, 0);
The problem is that hsotg->dev is assigned as follows:
static int dwc2_driver_probe(struct platform_device *dev)
...
hsotg = devm_kzalloc(&dev->dev, sizeof(*hsotg), GFP_KERNEL);
...
hsotg->dev = &dev->dev;
As such, it's not legal to call to_usb_device() on it.
What ends up happening, simply due to memory allocation order, is that
the memory writes inside usb_settoggle() end up setting the SDHCI struct
platform_device's num_resources to 0, so that it's call to
platform_get_resource() fails.
With the DWC2 move patch reverted, some other random piece of memory is
being corrupted, which just happens not to cause any visible problem.
Likely it's some other struct platform_device that's already had its
resources read by the time DWC2 probes and corrupts them.
(Yes, this was hard to find!)
I honestly can't see how to solve this myself, since the whole DWC2
driver doesn't seem to have a struct usb_device * hanging around that we
can stash somewhere for it to look up later. Perhaps someone more
familiar with the USB stack can help with that.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Move DWC2 driver out of staging
On 01/31/2014 12:37 PM, Paul Zimmerman wrote:
>> From: Andre Heider [mailto:a.hei...@gmail.com]
>> Sent: Friday, January 31, 2014 11:04 AM
>> On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
>>> On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> The DWC2 driver should now be in good enough shape to move out of
> staging. I have stress tested it overnight on RPI running mass
> storage and Ethernet transfers in parallel, and for several days
> on our proprietary PCI-based platform.
...
this looks just fine, but for whatever reason it breaks sdhci on my rpi.
With today's Linus' master the dwc2 controller seems to initialize fine,
but I get this upon boot:
[1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
[1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12
...
>> This silly move doesn't trigger the sdhci ENOMEM:
>>
>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>> index b021c96..f739b80 100644
>> --- a/arch/arm/boot/dts/bcm2835.dtsi
>> +++ b/arch/arm/boot/dts/bcm2835.dtsi
>> @@ -100,6 +100,12 @@
>> status = "disabled";
>> };
>>
>> +usb {
>> +compatible = "brcm,bcm2835-usb";
>> +reg = <0x7e98 0x1>;
>> +interrupts = <1 9>;
>> +};
>> +
>> sdhci: sdhci {
>> compatible = "brcm,bcm2835-sdhci";
>> reg = <0x7e30 0x100>;
>> @@ -107,12 +113,6 @@
>> clocks = <&clk_mmc>;
>> status = "disabled";
>> };
>> -
>> -usb {
>> -compatible = "brcm,bcm2835-usb";
>> -reg = <0x7e98 0x1>;
>> -interrupts = <1 9>;
>> -};
>> };
>>
>> clocks {
>>
>> Maybe there's some kind of race, or something even messing at the .dtb
>> at runtime?
>
> Hi Greg, Steve,
>
> Would moving a USB driver from drivers/staging/ to drivers/usb/ perhaps
> cause the initialization order to change?
Yes, certainly.
> If so, maybe that has exposed
> some pre-existing interference between sdhci and dwc2?
>
> Could moving the resource in the .dts file as Andre has done also cause
> the initialization order to change?
Yes, certainly.
I'll try to look into this, this weekend.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/31] ARM: tegra: use common reset and DMA bindings
On 11/15/2013 01:53 PM, Stephen Warren wrote: > From: Stephen Warren > > This series implements a common reset framework driver for Tegra, and > updates all relevant Tegra drivers to use it. It also removes the custom > DMA bindings and replaced them with the standard DMA DT bindings. > > Historically, the Tegra clock driver has exported a custom API for module > reset. This series removes that API, and transitions DT and drivers to > the new reset framework. > > The custom API used a "struct clk" to identify which module to reset, and > consequently some DT bindings and drivers required clocks to be provided > where they really needed just a reset identifier instead. Due to this > known deficiency, I have always considered most Tegra bindings to be > unstable. This series removes this excuse for instability, although I > still consider some Tegra bindings unstable due to the need to convert to > the common DMA bindings. > > Historically, Tegra DMA channels have been represented in DT using a > custom nvidia,dma-request-selector property. Now that standard DMA DT > bindings exist, convert all Tegra bindings, DTs, and drivers to use the > standard instead. > > This series makes a DT-ABI-incompatible change to: > - Require reset specifiers in DT where relevant. > - Require standard DMA specifiers. > - Remove clock specifiers from DT where they were only needed for reset. > - Remove legacy DMA specifier properties. > > I anticipate merging this whole series into the Tegra and arm-soc trees > as its own branch, due to internal dependencies. This branch will be > stable and can then be merged into any other subsystem trees should any > conflicts arise. > > This series depends on Peter's Tegra clock driver rework, available at > git://nv-tegra.nvidia.com/user/pdeschrijver/linux tegra-clk-tegra124-0 > (or whatever version of that gets included in 3.14) I've applied this series (and pulled in the DMA/ASoC/clk dependencies required) to Tegra's for-3.14/dmas-resets-rework branch. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dwc2: don't issue traffic to LS devices in FS mode
On 12/06/2013 03:01 PM, Paul Zimmerman wrote: > From: Nick Hudson > > I fell over the problem reported in > https://github.com/raspberrypi/linux/pull/390: > > "Issuing low-speed packets when the root port is in full-speed mode > causes the root port to stop responding. Explicitly fail when > enqueuing URBs to a LS endpoint on a FS bus." > > with my dwc2 testing in NetBSD, so I adapted the change to dwc2. Tested-by: Stephen Warren The built-in USB Ethernet on my model B still works fine with this change. A USB keyboard/mouse combo isn't reliable (it keeps dropping out, and I need to unplug/replug to get it working again), but it never was before. I'm also not sure if that's because of power issues or not (I'm not using powered hub on this system). ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dwc2: disable uframe_sched on the bcm2835
While Paul said that .uframe_sched should be enabled on the BCM2835,
and doing so works fine with the built-in wired Ethernet, it prevents
my WiFi dongle from operating correctly. Hence, disable the option so
that everything works.
Signed-off-by: Stephen Warren
---
drivers/staging/dwc2/platform.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 28a78fe..d01d0d3 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -72,7 +72,7 @@ static const struct dwc2_core_params params_bcm2835 = {
.ts_dline = 0,
.reload_ctl = 0,
.ahbcfg = 0x10,
- .uframe_sched = 1,
+ .uframe_sched = 0,
};
/**
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dwc2: set up all module params
(trimming out the devicetree list and maintainers for this discussion) On 11/26/2013 12:52 PM, Paul Zimmerman wrote: >> From: Stephen Warren [mailto:swar...@wwwdotorg.org] >> Sent: Tuesday, November 26, 2013 11:43 AM >> >> On 11/26/2013 12:27 PM, Paul Zimmerman wrote: >>>> From: Stephen Warren [mailto:swar...@wwwdotorg.org] >>>> Sent: Monday, November 25, 2013 9:03 PM >>>> >>>> The DWC2 USB controller in the BCM2835 (Raspberry Pi) needs some non- >>>> default parameters. Select these based on the compatible value from the >>>> DT node. For all other HW, fall back to the default parameters currently >>>> in use. >>>> >>>> The values in params_bcm2835[] were posted to the mailing list by Paul >>>> quite some time ago. I made a couple of minor modifications since then; >>>> to set ahbcfg instead of ahb_single, and to set uframe_sched. >>> >>> Hi Stephen, >>> >>> I don't see any code in this patch that is setting uframe_sched? >> >> Hmm, that's true. What value should it be set to for the BCM2835, do you >> know? I obviously have it set to 0, which seems to work out OK... > > It definitely should be enabled for the Pi, so set it to 1. Hmm. I should have tested that patch better before I sent it... With .uframe_sched=1, my model B's built-in Ethernet chip works fine. I've passed many MB of data through it without issue, including pings, a kernel source download, and package updates. However, I just enabled .uframe_sched=1 on my model A, which has a USB hub and USB wireless dongle attached. Now USB enumeration doesn't work, and booting the kernel is extremely slow, with lots of USB-related messages. I've run that board for a few days straight without issue, with .uframe_sched=0 and periodic network use. Does this imply that .uframe_sched=1 isn't correct for the Pi, or that the code that flag enables has issues? FWIW, the problematic kernel log is below. Unfortunately, I can't debug this much since that Pi is deployed "in production" in my daughter's room, and she's (hopefully...) asleep. I'll also be away starting tomorrow morning until Mon evening. > [1.907615] dwc2 2098.usb: DWC OTG Controller > [1.915043] dwc2 2098.usb: new USB bus registered, assigned bus number > 1 > [1.924766] dwc2 2098.usb: irq 33, io mem 0x > [1.932906] usb usb1: default language 0x0409 > [1.939969] usb usb1: udev 1, busnum 1, minor = 0 > [1.947325] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [1.956906] usb usb1: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [1.966981] usb usb1: Product: DWC OTG Controller > [1.974570] usb usb1: Manufacturer: Linux 3.13.0-rc1-next-20131125+ > dwc2_hsotg > [1.984841] usb usb1: SerialNumber: 2098.usb > [1.993202] usb usb1: usb_probe_device > [2.66] usb usb1: configuration #1 chosen from 1 choice > [2.008968] usb usb1: adding 1-0:1.0 (config #1, interface 0) > [2.018227] hub 1-0:1.0: usb_probe_interface > [2.025763] hub 1-0:1.0: usb_probe_interface - got id > [2.033990] hub 1-0:1.0: USB hub found > [2.040891] hub 1-0:1.0: 1 port detected > [2.047796] hub 1-0:1.0: standalone hub > [2.054580] hub 1-0:1.0: ganged power switching > [2.061983] hub 1-0:1.0: individual port over-current protection > [2.070833] hub 1-0:1.0: Single TT > [2.076944] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns) > [2.086102] hub 1-0:1.0: power on to power good time: 2ms > [2.094549] hub 1-0:1.0: local power source is good > [2.102344] hub 1-0:1.0: enabling power on all ports > [2.112008] tsl2563 1-0039: model 5, rev. 0 > [2.121210] oprofile: no performance counters > [2.128318] oprofile: using timer interrupt. > [2.135673] TCP: cubic registered > [2.142836] NET: Registered protocol family 10 > [2.151272] sit: IPv6 over IPv4 tunneling driver > [2.159514] NET: Registered protocol family 17 > [2.180761] kjournald starting. Commit interval 5 seconds > [2.198444] EXT3-fs (mmcblk0p2): using internal journal > [2.206507] hub 1-0:1.0: port 1: status 0101 change 0001 > [2.214470] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode > [2.224234] VFS: Mounted root (ext3 filesystem) on device 179:2. > [2.235386] devtmpfs: mounted > [2.242299] Freeing unused kernel memory: 364K (c062b000 - c0686000) > [2.320341] hub 1-0:1.0: state 7 ports 1 chg 0002 evt > [2.329613] hub 1-0:1.0: port 1, status 0101, change , 12 Mb/s > [2.530412] usb 1-1: new high-speed USB device num
[PATCH V2] staging: dwc2: set up all module params
The DWC2 USB controller in the BCM2835 (Raspberry Pi) needs some non-
default parameters. Select these based on the compatible value from the
DT node. For all other HW, fall back to the default parameters currently
in use.
The values in params_bcm2835[] were posted to the mailing list by Paul
quite some time ago. I made a couple of minor modifications since then;
to set ahbcfg instead of ahb_single, and to set uframe_sched.
Signed-off-by: Stephen Warren
---
v2:
* Handle !match->data correctly.
* Set uframe_sched core parameter.
---
Documentation/devicetree/bindings/staging/dwc2.txt |4 +-
drivers/staging/dwc2/platform.c| 58
2 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt
b/Documentation/devicetree/bindings/staging/dwc2.txt
index 1a1b7cf..8b60e90 100644
--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -2,7 +2,9 @@ Platform DesignWare HS OTG USB 2.0 controller
-
Required properties:
-- compatible : "snps,dwc2"
+- compatible : One of:
+ - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+ - snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 4d9fac0..28a78fe 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include "core.h"
@@ -46,6 +47,34 @@
static const char dwc2_driver_name[] = "dwc2";
+static const struct dwc2_core_params params_bcm2835 = {
+ .otg_cap= 0,/* HNP/SRP capable */
+ .otg_ver= 0,/* 1.3 */
+ .dma_enable = 1,
+ .dma_desc_enable= 0,
+ .speed = 0,/* High Speed */
+ .enable_dynamic_fifo= 1,
+ .en_multiple_tx_fifo= 1,
+ .host_rx_fifo_size = 774, /* 774 DWORDs */
+ .host_nperio_tx_fifo_size = 256, /* 256 DWORDs */
+ .host_perio_tx_fifo_size= 512, /* 512 DWORDs */
+ .max_transfer_size = 65535,
+ .max_packet_count = 511,
+ .host_channels = 8,
+ .phy_type = 1,/* UTMI */
+ .phy_utmi_width = 8,/* 8 bits */
+ .phy_ulpi_ddr = 0,/* Single */
+ .phy_ulpi_ext_vbus = 0,
+ .i2c_enable = 0,
+ .ulpi_fs_ls = 0,
+ .host_support_fs_ls_low_power = 0,
+ .host_ls_low_power_phy_clk = 0,/* 48 MHz */
+ .ts_dline = 0,
+ .reload_ctl = 0,
+ .ahbcfg = 0x10,
+ .uframe_sched = 1,
+};
+
/**
* dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
* DWC_otg driver
@@ -66,6 +95,13 @@ static int dwc2_driver_remove(struct platform_device *dev)
return 0;
}
+static const struct of_device_id dwc2_of_match_table[] = {
+ { .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
+ { .compatible = "snps,dwc2", .data = NULL },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
+
/**
* dwc2_driver_probe() - Called when the DWC_otg core is bound to the DWC_otg
* driver
@@ -80,14 +116,22 @@ static int dwc2_driver_remove(struct platform_device *dev)
*/
static int dwc2_driver_probe(struct platform_device *dev)
{
+ const struct of_device_id *match;
+ const struct dwc2_core_params *params;
+ struct dwc2_core_params defparams;
struct dwc2_hsotg *hsotg;
struct resource *res;
int retval;
int irq;
- struct dwc2_core_params params;
- /* Default all params to autodetect */
- dwc2_set_all_params(¶ms, -1);
+ match = of_match_device(dwc2_of_match_table, &dev->dev);
+ if (match && match->data) {
+ params = match->data;
+ } else {
+ /* Default all params to autodetect */
+ dwc2_set_all_params(&defparams, -1);
+ params = &defparams;
+ }
hsotg = devm_kzalloc(&dev->dev, sizeof(*hsotg), GFP_KERNEL);
if (!hsotg)
@@ -118,7 +162,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(&dev->dev, "mapped PA %08lx to VA %p\n",
(unsigned long)res->start, hsotg->regs);
- retval = dwc2_hcd_init(hsotg, irq, ¶ms);
+ re
Re: [PATCH] staging: dwc2: set up all module params
On 11/26/2013 12:27 PM, Paul Zimmerman wrote: >> From: Stephen Warren [mailto:swar...@wwwdotorg.org] >> Sent: Monday, November 25, 2013 9:03 PM >> >> The DWC2 USB controller in the BCM2835 (Raspberry Pi) needs some non- >> default parameters. Select these based on the compatible value from the >> DT node. For all other HW, fall back to the default parameters currently >> in use. >> >> The values in params_bcm2835[] were posted to the mailing list by Paul >> quite some time ago. I made a couple of minor modifications since then; >> to set ahbcfg instead of ahb_single, and to set uframe_sched. > > Hi Stephen, > > I don't see any code in this patch that is setting uframe_sched? Hmm, that's true. What value should it be set to for the BCM2835, do you know? I obviously have it set to 0, which seems to work out OK... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dwc2: set up all module params
The DWC2 USB controller in the BCM2835 (Raspberry Pi) needs some non-
default parameters. Select these based on the compatible value from the
DT node. For all other HW, fall back to the default parameters currently
in use.
The values in params_bcm2835[] were posted to the mailing list by Paul
quite some time ago. I made a couple of minor modifications since then;
to set ahbcfg instead of ahb_single, and to set uframe_sched.
Signed-off-by: Stephen Warren
---
Documentation/devicetree/bindings/staging/dwc2.txt |4 +-
drivers/staging/dwc2/platform.c| 56
2 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt
b/Documentation/devicetree/bindings/staging/dwc2.txt
index 1a1b7cf..8b60e90 100644
--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -2,7 +2,9 @@ Platform DesignWare HS OTG USB 2.0 controller
-
Required properties:
-- compatible : "snps,dwc2"
+- compatible : One of:
+ - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+ - snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 4d9fac0..20586dc 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include "core.h"
@@ -46,6 +47,33 @@
static const char dwc2_driver_name[] = "dwc2";
+static const struct dwc2_core_params params_bcm2835 = {
+ .otg_cap= 0,/* HNP/SRP capable */
+ .otg_ver= 0,/* 1.3 */
+ .dma_enable = 1,
+ .dma_desc_enable= 0,
+ .speed = 0,/* High Speed */
+ .enable_dynamic_fifo= 1,
+ .en_multiple_tx_fifo= 1,
+ .host_rx_fifo_size = 774, /* 774 DWORDs */
+ .host_nperio_tx_fifo_size = 256, /* 256 DWORDs */
+ .host_perio_tx_fifo_size= 512, /* 512 DWORDs */
+ .max_transfer_size = 65535,
+ .max_packet_count = 511,
+ .host_channels = 8,
+ .phy_type = 1,/* UTMI */
+ .phy_utmi_width = 8,/* 8 bits */
+ .phy_ulpi_ddr = 0,/* Single */
+ .phy_ulpi_ext_vbus = 0,
+ .i2c_enable = 0,
+ .ulpi_fs_ls = 0,
+ .host_support_fs_ls_low_power = 0,
+ .host_ls_low_power_phy_clk = 0,/* 48 MHz */
+ .ts_dline = 0,
+ .reload_ctl = 0,
+ .ahbcfg = 0x10,
+};
+
/**
* dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
* DWC_otg driver
@@ -66,6 +94,13 @@ static int dwc2_driver_remove(struct platform_device *dev)
return 0;
}
+static const struct of_device_id dwc2_of_match_table[] = {
+ { .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
+ { .compatible = "snps,dwc2", .data = NULL },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
+
/**
* dwc2_driver_probe() - Called when the DWC_otg core is bound to the DWC_otg
* driver
@@ -80,14 +115,23 @@ static int dwc2_driver_remove(struct platform_device *dev)
*/
static int dwc2_driver_probe(struct platform_device *dev)
{
+ const struct of_device_id *match;
+ const struct dwc2_core_params *params;
+ struct dwc2_core_params defparams;
struct dwc2_hsotg *hsotg;
struct resource *res;
int retval;
int irq;
- struct dwc2_core_params params;
+
+ match = of_match_device(dwc2_of_match_table, &dev->dev);
+ if (match)
+ params = match->data;
+ else {
+ dwc2_set_all_params(&defparams, -1);
+ params = &defparams;
+ }
/* Default all params to autodetect */
- dwc2_set_all_params(¶ms, -1);
hsotg = devm_kzalloc(&dev->dev, sizeof(*hsotg), GFP_KERNEL);
if (!hsotg)
@@ -118,7 +162,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(&dev->dev, "mapped PA %08lx to VA %p\n",
(unsigned long)res->start, hsotg->regs);
- retval = dwc2_hcd_init(hsotg, irq, ¶ms);
+ retval = dwc2_hcd_init(hsotg, irq, params);
if (retval)
return retval;
@@ -127,12 +171,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
return retval;
Re: [PATCH 00/31] ARM: tegra: use common reset and DMA bindings
On 11/20/2013 10:03 AM, Arnd Bergmann wrote:
> On Wednesday 20 November 2013, Stephen Warren wrote:
>>> +- #iommu-cells : Must be <1>. This dictates the length of DMA specifiers in
>>> + client nodes' dmas properties. The specifier represents the DMA request
>>> + select value for the peripheral. For more details, consult the Tegra
>>> TRM's
>>> + documentation of the APB DMA channel control register REQ_SEL field.
>>>
>>> Examples:
>>>
>>> @@ -36,4 +40,5 @@ apbdma: dma@6000a000 {
>>> clocks = <&tegra_car 34>;
>>> resets = <&tegra_car 34>;
>>> reset-names = "dma";
>>> + #iommu-cells = <1>;
>
>
> s/iommu/dma/
>
> Otherwise looks good. The dts files are correct, so I guess it's just
> a typo here.
Thanks, fixed locally.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/31] ARM: tegra: use common reset and DMA bindings
On 11/20/2013 08:37 AM, Arnd Bergmann wrote:
> On Friday 15 November 2013, Stephen Warren wrote:
>> This series implements a common reset framework driver for Tegra, and
>> updates all relevant Tegra drivers to use it. It also removes the custom
>> DMA bindings and replaced them with the standard DMA DT bindings.
>
> The series is rather long, so I may have missed it, but I think you need one
> more patch to the apbdma binding to document the use of #dma-cells, what
> value it has, and what the format of the dma specifiers in slave drivers
> needs to be.
Yes, you're right. I will fold the following into "ARM: tegra: document
use of standard DMA DT bindings":
> diff --git a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> index 0b1e577ab9d3..0b0f9498e265 100644
> --- a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> +++ b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
> @@ -11,6 +11,10 @@ Required properties:
>See ../reset/reset.txt for details.
> - reset-names : Must include the following entries:
>- dma
> +- #iommu-cells : Must be <1>. This dictates the length of DMA specifiers in
> + client nodes' dmas properties. The specifier represents the DMA request
> + select value for the peripheral. For more details, consult the Tegra TRM's
> + documentation of the APB DMA channel control register REQ_SEL field.
>
> Examples:
>
> @@ -36,4 +40,5 @@ apbdma: dma@6000a000 {
> clocks = <&tegra_car 34>;
> resets = <&tegra_car 34>;
> reset-names = "dma";
> + #iommu-cells = <1>;
> };
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 21/31] staging: nvec: use reset framework
From: Stephen Warren
Tegra's clock driver now provides an implementation of the common
reset API (include/linux/reset.h). Use this instead of the old Tegra-
specific API; that will soon be removed.
Cc: tred...@nvidia.com
Cc: pdeschrij...@nvidia.com
Cc: linux-te...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: Julian Andres Klode
Cc: Marc Dietrich
Cc: ac...@lists.launchpad.net
Cc: Greg Kroah-Hartman
Cc: de...@driverdev.osuosl.org
Signed-off-by: Stephen Warren
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
---
drivers/staging/nvec/nvec.c | 11 ---
drivers/staging/nvec/nvec.h | 5 -
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 3066ee2e753b..9de4cd13d9ab 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -36,7 +36,6 @@
#include
#include
#include
-#include
#include "nvec.h"
@@ -733,9 +732,9 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
clk_prepare_enable(nvec->i2c_clk);
- tegra_periph_reset_assert(nvec->i2c_clk);
+ reset_control_assert(nvec->rst);
udelay(2);
- tegra_periph_reset_deassert(nvec->i2c_clk);
+ reset_control_deassert(nvec->rst);
val = I2C_CNFG_NEW_MASTER_SFM | I2C_CNFG_PACKET_MODE_EN |
(0x2 << I2C_CNFG_DEBOUNCE_CNT_SHIFT);
@@ -836,6 +835,12 @@ static int tegra_nvec_probe(struct platform_device *pdev)
return -ENODEV;
}
+ nvec->rst = devm_reset_control_get(&pdev->dev, "i2c");
+ if (IS_ERR(nvec->rst)) {
+ dev_err(nvec->dev, "failed to get controller reset\n");
+ return PTR_ERR(nvec->rst);
+ }
+
nvec->base = base;
nvec->irq = res->start;
nvec->i2c_clk = i2c_clk;
diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec/nvec.h
index e880518935fb..e271375053fa 100644
--- a/drivers/staging/nvec/nvec.h
+++ b/drivers/staging/nvec/nvec.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -109,7 +110,8 @@ struct nvec_msg {
* @irq: The IRQ of the I2C device
* @i2c_addr: The address of the I2C slave
* @base: The base of the memory mapped region of the I2C device
- * @clk: The clock of the I2C device
+ * @i2c_clk: The clock of the I2C device
+ * @rst: The reset of the I2C device
* @notifier_list: Notifiers to be called on received messages, see
* nvec_register_notifier()
* @rx_data: Received messages that have to be processed
@@ -139,6 +141,7 @@ struct nvec_chip {
int i2c_addr;
void __iomem *base;
struct clk *i2c_clk;
+ struct reset_control *rst;
struct atomic_notifier_head notifier_list;
struct list_head rx_data, tx_data;
struct notifier_block nvec_status_notifier;
--
1.8.1.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/31] ARM: tegra: use common reset and DMA bindings
From: Stephen Warren This series implements a common reset framework driver for Tegra, and updates all relevant Tegra drivers to use it. It also removes the custom DMA bindings and replaced them with the standard DMA DT bindings. Historically, the Tegra clock driver has exported a custom API for module reset. This series removes that API, and transitions DT and drivers to the new reset framework. The custom API used a "struct clk" to identify which module to reset, and consequently some DT bindings and drivers required clocks to be provided where they really needed just a reset identifier instead. Due to this known deficiency, I have always considered most Tegra bindings to be unstable. This series removes this excuse for instability, although I still consider some Tegra bindings unstable due to the need to convert to the common DMA bindings. Historically, Tegra DMA channels have been represented in DT using a custom nvidia,dma-request-selector property. Now that standard DMA DT bindings exist, convert all Tegra bindings, DTs, and drivers to use the standard instead. This series makes a DT-ABI-incompatible change to: - Require reset specifiers in DT where relevant. - Require standard DMA specifiers. - Remove clock specifiers from DT where they were only needed for reset. - Remove legacy DMA specifier properties. I anticipate merging this whole series into the Tegra and arm-soc trees as its own branch, due to internal dependencies. This branch will be stable and can then be merged into any other subsystem trees should any conflicts arise. This series depends on Peter's Tegra clock driver rework, available at git://nv-tegra.nvidia.com/user/pdeschrijver/linux tegra-clk-tegra124-0 (or whatever version of that gets included in 3.14) Cc: ac...@lists.launchpad.net Cc: Alan Stern Cc: alsa-de...@alsa-project.org Cc: Bjorn Helgaas Cc: Dan Williams Cc: David Airlie Cc: de...@driverdev.osuosl.org Cc: devicet...@vger.kernel.org Cc: Dmitry Torokhov Cc: Dmitry Torokhov Cc: dri-de...@lists.freedesktop.org Cc: Greg Kroah-Hartman Cc: Ian Campbell Cc: Julian Andres Klode Cc: Liam Girdwood Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: Marc Dietrich Cc: Mark Brown Cc: Mark Rutland Cc: Mike Turquette Cc: Pawel Moll Cc: pdeschrij...@nvidia.com Cc: Rob Herring Cc: Terje Bergström Cc: tred...@nvidia.com Cc: Wolfram Sang Stephen Warren (31): ARM: tegra: add missing clock documentation to DT bindings ARM: tegra: document reset properties in DT bindings ARM: tegra: document use of standard DMA DT bindings ARM: tegra: update DT files to add reset properties ARM: tegra: update DT files to add DMA properties ARM: tegra: select the reset framework clk: tegra: implement a reset driver pci: tegra: use reset framework drm/tegra: use reset framework ARM: tegra: pass reset to tegra_powergate_sequence_power_up() dma: add channel request API that supports deferred probe dma: tegra: use reset framework dma: tegra: register as an OF DMA controller ASoC: dmaengine: support deferred probe for DMA channels ASoC: dmaengine: add custom DMA config to snd_dmaengine_pcm_config ASoC: tegra: use reset framework ASoC: tegra: call pm_runtime APIs around register accesses ASoC: tegra: allocate AHUB FIFO during probe() not startup() ASoC: tegra: convert to standard DMA DT bindings i2c: tegra: use reset framework staging: nvec: use reset framework spi: tegra: use reset framework spi: tegra: convert to standard DMA DT bindings serial: tegra: use reset framework serial: tegra: convert to standard DMA DT bindings Input: tegra-kbc - use reset framework USB: EHCI: tegra: use reset framework ARM: tegra: remove legacy clock entries from DT ARM: tegra: remove legacy DMA entries from DT clk: tegra: remove legacy reset APIs clk: tegra: remove bogus PCIE_XCLK .../bindings/arm/tegra/nvidia,tegra20-pmc.txt | 1 + .../bindings/clock/nvidia,tegra114-car.txt | 4 + .../bindings/clock/nvidia,tegra124-car.txt | 4 + .../bindings/clock/nvidia,tegra20-car.txt | 4 + .../bindings/clock/nvidia,tegra30-car.txt | 4 + .../devicetree/bindings/dma/tegra20-apbdma.txt | 9 ++ .../bindings/gpu/nvidia,tegra20-host1x.txt | 124 +++ .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 27 +++- .../bindings/input/nvidia,tegra20-kbc.txt | 9 ++ .../bindings/mmc/nvidia,tegra20-sdhci.txt | 9 ++ .../devicetree/bindings/nvec/nvidia,nvec.txt | 12 ++ .../bindings/pci/nvidia,tegra20-pcie.txt | 28 ++-- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 9 ++ .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt | 3 + .../bindings/serial/nvidia,tegra20-hsuart
Re: [PATCH] staging: dwc2: add microframe scheduler from downstream Pi kernel
On 07/17/2013 01:35 PM, Paul Zimmerman wrote: > The transfer scheduler in the dwc2 driver is pretty basic, not to > mention buggy. It works fairly well with just a couple of devices > plugged in, but if you add, say, multiple devices with periodic > endpoints, the scheduler breaks down and can't even enumerate all > the devices. > > To fix this, import the "microframe scheduler" patch from the > driver in the downstream Raspberry Pi kernel, which is based on > the Synopsys vendor driver. That patch was done by the guys from > raspberrypi.org, including at least Gordon Hollingsworth and > "popcornmix". > > I have added a driver parameter for this, enabled by default, in > case anyone has problems with it and needs to disable it. I don't > think we should add a DT binding for that, though, since I plan to > remove the option once any bugs are fixed. Tested-by: Stephen Warren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dwc2: add driver parameter to set AHB config register value
On 07/16/2013 01:22 PM, Paul Zimmerman wrote: > The dwc2 driver sets the value of the DWC2 GAHBCFG register to 0x6, > which is GAHBCFG_HBSTLEN_INCR4. But different platforms may require > different values. In particular, the Broadcom 2835 SOC used in the > Raspberry Pi needs a value of 0x10, otherwise the DWC2 controller > stops working after a short period of heavy USB traffic. > > So this patch adds another driver parameter named 'ahbcfg'. The > default value is 0x6. Any platform needing a different value should > add a DT attribute to set it. > > This patch also removes the 'ahb_single' driver parameter, since > that bit can now be set using 'ahbcfg'. > > This patch does not add DT support to platform.c, I will leave that > to whoever owns the first platform that needs a non-default value. > (Stephen?) Tested-by: Stephen Warren ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dwc2: add microframe scheduler from downstream Pi kernel
On 07/18/2013 10:45 AM, Paul Zimmerman wrote: >> From: linux-usb-ow...@vger.kernel.org >> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Gordon Hollingworth >> Sent: Wednesday, July 17, 2013 11:00 PM >> >> I'd suggest just adding a Raspberry Pi Foundation copyright. >> >> Is that OK or do you need names for SOB? > > Ah yes, thanks for reminding me. Yes, I will need SOBs from the main > contributors. And they must be real names, "popcornmix" is not > acceptable as far as I understand. Thanks. BTW, Dom has previously given permission to me (I think in an email posted to a public list) to modify any S-o-b lines that say "popcornmix" as the real name to say "Dom Cobley" instead. Of course, this is only relevant if the commit in question is already s-o-b popcornmix. And I am assuming that popcornmix is always Dom. (Greg, I assume this kind of agreement is fine, and it's not the case that Dom would need to amend all his commits himself to change the s-o-b?) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] staging: dwc2: fixes and cleanups for dwc2
On 07/13/2013 03:53 PM, Paul Zimmerman wrote: > This is a series of fixes and cleanups for the dwc2 driver. It > fixes some occasional crashes I had been seeing, and also makes > the driver work on the Raspberry Pi with the mainline kernel, > once some additional DT support is added (not upstream yet). > > I think this should make the driver pretty close to mainlineable > too. The series, Tested-by: Stephen Warren The overall result isn't *quite* perfect, but it's a heck of a lot better than it was before. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
