Re: [PATCH 1/4 v3] drm: Add support of ARC PGU display controller
On Tue, Mar 15, 2016 at 03:24:46PM +, Alexey Brodkin wrote: > Hi Daniel, > > On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote: > > On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote: > > > > > > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote: > > > > > > > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote: > > > > > > > > > > +static int arcpgu_atomic_commit(struct drm_device *dev, > > > > > + struct drm_atomic_state *state, > > > > > bool async) > > > > > +{ > > > > > + return drm_atomic_helper_commit(dev, state, false); > > > > Note that this isn't really async if you ever get around to implement > > > > fence support or vblank support. Just fyi. > > > Ok but for now should I leave it as it is? > > Yeah ok as-is, hence just fyi. > > Thanks. Just wanted to make sure we're on the same page :) > > > > > > > > > > > > > > > > > > +static struct drm_driver arcpgu_drm_driver = { > > > > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | > > > > > + DRIVER_ATOMIC, > > > > > + .preclose = arcpgu_preclose, > > > > > + .lastclose = arcpgu_lastclose, > > > > > + .name = "drm-arcpgu", > > > > > + .desc = "ARC PGU Controller", > > > > > + .date = "20160219", > > > > > + .major = 1, > > > > > + .minor = 0, > > > > > + .patchlevel = 0, > > > > > + .fops = &arcpgu_drm_ops, > > > > > + .load = arcpgu_load, > > > > > + .unload = arcpgu_unload, > > > > Load and unload hooks are deprecated (it's a classic midlayer mistake). > > > > Please use drm_dev_alloc/register pairs directly instead, and put your > > > > device setup code in-between. Similar for unloading. There's a bunch of > > > > example drivers converted already. > > > Ok I took "atmel-hlcdc" as example. > > > And that's interesting. > > > > > > If I put my arcpgu_load() in between drm_dev_alloc() and > > > drm_dev_register() then I'm getting this on the driver probe: > > > -->8--- > > > [drm] Initialized drm 1.1.0 20060810 > > > arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab > > > [ cut here ] > > > WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 > > > kobject_add_internal+0x17c/0x498() > > > kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0) > > > Modules linked in: > > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17 > > > > > > Stack Trace: > > > arc_unwind_core.constprop.1+0xa4/0x110 > > > warn_slowpath_fmt+0x6e/0xfc > > > kobject_add_internal+0x17c/0x498 > > > kobject_add+0x98/0xe4 > > > device_add+0xc6/0x734 > > > device_create_with_groups+0x12a/0x144 > > > drm_sysfs_connector_add+0x54/0xe8 > > > arcpgu_drm_hdmi_init+0xd4/0x17c > > > arcpgu_probe+0x138/0x24c > > > platform_drv_probe+0x2e/0x6c > > > really_probe+0x212/0x35c > > > __driver_attach+0x90/0x94 > > > bus_for_each_dev+0x46/0x80 > > > bus_add_driver+0x14e/0x1b4 > > > driver_register+0x64/0x108 > > > do_one_initcall+0x86/0x194 > > > kernel_init_freeable+0xf0/0x188 > > > ---[ end trace c67166ad43ddcce2 ]--- > > > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs > > > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector > > > device: -2 > > > arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs > > > arcpgu: probe of e0017000.pgu failed with error -2 > > > -->8--- > > > > > > But if I move arcpgu_load() after drm_dev_register() then everything > > > starts properly and I may see HDMI screen works perfectly fine. > > > > > > Any thoughts? > > Oops, yeah missed that detail. If you look at atmel it has a loop to > > register all the drm connectors _after_ calling drm_dev_register(). > > Totally forgot about that. Can you pls > > - Extract a new drm_connector_register_all() function > > (atmel_hlcdc_dc_connector_plug_all seems to be the best template), > > including kerneldoc. > > - Adjust kerneldoc of drm_dev_register() to mention > > drm_connector_register_all() and that ordering constraint. > > - Roll that helper out to all the drivers that currently hand-roll it (one > > patch per driver). > > > > I know a bit of work but imo not too much, and by doing some small > > refactoring every time someone stumbles over a drm pitfall we keep the > > subsystem clean&easy to understand. You're up for this? Would be a prep > > series, I'll happily review it to get it merged fast. Just a few weeks ago > > I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy > > ones all over the subsystem, in other words: You'll have my full attention > > ;-) > > Sure, I'm ready to pay that price :) > Stay tuned and patches will follow. Awesome, looking forward to your patches. > > > > > > > > > > > > > > > > > + .dumb_create = drm_gem_cma_dumb_create, > >
Re: [PATCH 1/4 v3] drm: Add support of ARC PGU display controller
Hi Daniel, On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote: > On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote: > > > > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote: > > > > > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote: > > > > > > > > +static int arcpgu_atomic_commit(struct drm_device *dev, > > > > + struct drm_atomic_state *state, > > > > bool async) > > > > +{ > > > > + return drm_atomic_helper_commit(dev, state, false); > > > Note that this isn't really async if you ever get around to implement > > > fence support or vblank support. Just fyi. > > Ok but for now should I leave it as it is? > Yeah ok as-is, hence just fyi. Thanks. Just wanted to make sure we're on the same page :) > > > > > > > > > > > > > +static struct drm_driver arcpgu_drm_driver = { > > > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | > > > > + DRIVER_ATOMIC, > > > > + .preclose = arcpgu_preclose, > > > > + .lastclose = arcpgu_lastclose, > > > > + .name = "drm-arcpgu", > > > > + .desc = "ARC PGU Controller", > > > > + .date = "20160219", > > > > + .major = 1, > > > > + .minor = 0, > > > > + .patchlevel = 0, > > > > + .fops = &arcpgu_drm_ops, > > > > + .load = arcpgu_load, > > > > + .unload = arcpgu_unload, > > > Load and unload hooks are deprecated (it's a classic midlayer mistake). > > > Please use drm_dev_alloc/register pairs directly instead, and put your > > > device setup code in-between. Similar for unloading. There's a bunch of > > > example drivers converted already. > > Ok I took "atmel-hlcdc" as example. > > And that's interesting. > > > > If I put my arcpgu_load() in between drm_dev_alloc() and > > drm_dev_register() then I'm getting this on the driver probe: > > -->8--- > > [drm] Initialized drm 1.1.0 20060810 > > arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab > > [ cut here ] > > WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 > > kobject_add_internal+0x17c/0x498() > > kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0) > > Modules linked in: > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17 > > > > Stack Trace: > > arc_unwind_core.constprop.1+0xa4/0x110 > > warn_slowpath_fmt+0x6e/0xfc > > kobject_add_internal+0x17c/0x498 > > kobject_add+0x98/0xe4 > > device_add+0xc6/0x734 > > device_create_with_groups+0x12a/0x144 > > drm_sysfs_connector_add+0x54/0xe8 > > arcpgu_drm_hdmi_init+0xd4/0x17c > > arcpgu_probe+0x138/0x24c > > platform_drv_probe+0x2e/0x6c > > really_probe+0x212/0x35c > > __driver_attach+0x90/0x94 > > bus_for_each_dev+0x46/0x80 > > bus_add_driver+0x14e/0x1b4 > > driver_register+0x64/0x108 > > do_one_initcall+0x86/0x194 > > kernel_init_freeable+0xf0/0x188 > > ---[ end trace c67166ad43ddcce2 ]--- > > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs > > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: > > -2 > > arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs > > arcpgu: probe of e0017000.pgu failed with error -2 > > -->8--- > > > > But if I move arcpgu_load() after drm_dev_register() then everything > > starts properly and I may see HDMI screen works perfectly fine. > > > > Any thoughts? > Oops, yeah missed that detail. If you look at atmel it has a loop to > register all the drm connectors _after_ calling drm_dev_register(). > Totally forgot about that. Can you pls > - Extract a new drm_connector_register_all() function > (atmel_hlcdc_dc_connector_plug_all seems to be the best template), > including kerneldoc. > - Adjust kerneldoc of drm_dev_register() to mention > drm_connector_register_all() and that ordering constraint. > - Roll that helper out to all the drivers that currently hand-roll it (one > patch per driver). > > I know a bit of work but imo not too much, and by doing some small > refactoring every time someone stumbles over a drm pitfall we keep the > subsystem clean&easy to understand. You're up for this? Would be a prep > series, I'll happily review it to get it merged fast. Just a few weeks ago > I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy > ones all over the subsystem, in other words: You'll have my full attention > ;-) Sure, I'm ready to pay that price :) Stay tuned and patches will follow. > > > > > > > > > > > > > + .dumb_create = drm_gem_cma_dumb_create, > > > > + .dumb_map_offset = drm_gem_cma_dumb_map_offset, > > > > + .dumb_destroy = drm_gem_dumb_destroy, > > > > + .get_vblank_counter = drm_vblank_no_hw_counter, > > > > + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > > > > + .prime_fd_to_handle = drm_gem_prime_fd_
Re: [PATCH] ARC: axs10x - add Ethernet PHY description in .dts
Hi Sergei, On Tue, 2016-03-15 at 17:38 +0300, Sergei Shtylyov wrote: > Hello. > > On 3/15/2016 12:29 PM, Alexey Brodkin wrote: > > > > > Following commit broke DW GMAC functionality on AXS10x boards: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763 > > > > That's what happens on eth0 up: > > --->8 > > libphy: PHY stmmac-0: not found > > eth0: Could not attach to PHY > > stmmac_open: Cannot attach to PHY (error: -19) > > --->8 > > > > Simplest solution is to add PHY description in board's .dts. > > And so we do here. > > > > Signed-off-by: Alexey Brodkin > > Cc: Rob Herring > > Cc: Phil Reid > > Cc: David S. Miller > > Cc: linux-ker...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Cc: sta...@vger.kernel.org # 4.5.x > > --- > > arch/arc/boot/dts/axs10x_mb.dtsi | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi > > b/arch/arc/boot/dts/axs10x_mb.dtsi > > index 44a578c..04b999e 100644 > > --- a/arch/arc/boot/dts/axs10x_mb.dtsi > > +++ b/arch/arc/boot/dts/axs10x_mb.dtsi > > @@ -47,6 +47,14 @@ > > clocks = <&apbclk>; > > clock-names = "stmmaceth"; > > max-speed = <100>; > > + mdio0 { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + compatible = "snps,dwmac-mdio"; > > + phy0: ethernet-phy@0 { > The naming is inconsistent with the "reg" prop specified, should be @1. Makes sense. Will re-send it with mentioned fix. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: axs10x - add Ethernet PHY description in .dts
Hello. On 3/15/2016 12:29 PM, Alexey Brodkin wrote: Following commit broke DW GMAC functionality on AXS10x boards: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763 That's what happens on eth0 up: --->8 libphy: PHY stmmac-0: not found eth0: Could not attach to PHY stmmac_open: Cannot attach to PHY (error: -19) --->8 Simplest solution is to add PHY description in board's .dts. And so we do here. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Phil Reid Cc: David S. Miller Cc: linux-ker...@vger.kernel.org Cc: net...@vger.kernel.org Cc: sta...@vger.kernel.org # 4.5.x --- arch/arc/boot/dts/axs10x_mb.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi index 44a578c..04b999e 100644 --- a/arch/arc/boot/dts/axs10x_mb.dtsi +++ b/arch/arc/boot/dts/axs10x_mb.dtsi @@ -47,6 +47,14 @@ clocks = <&apbclk>; clock-names = "stmmaceth"; max-speed = <100>; + mdio0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + phy0: ethernet-phy@0 { The naming is inconsistent with the "reg" prop specified, should be @1. MBR, Sergei ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Remove the inclusion of pci-bridge.h and pci-dma-compat.h
No problem! Thanks! On 3/15/2016 1:51 PM, Bjorn Helgaas wrote: > On Tue, Mar 15, 2016 at 11:06:02AM +, Joao Pinto wrote: >> While building linux-next the test robot detected that the pci.h was >> including >> two removed header files (pci-dma-compat.h and pci-bridge.h) causing the >> process to fail: >> http://lists.infradead.org/pipermail/linux-snps-arc/2016-March/000711.html >> >> This patch has the goal to fix the build problem. >> >> Signed-off-by: Joao Pinto > > Thanks, Joao, I folded this fix into the original commit. I should have > caught this myself, since I'm the one who removed pci-bridge.h. > >> --- >> arch/arc/include/asm/pci.h | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/arch/arc/include/asm/pci.h b/arch/arc/include/asm/pci.h >> index 2f2011c..ba56c23 100644 >> --- a/arch/arc/include/asm/pci.h >> +++ b/arch/arc/include/asm/pci.h >> @@ -10,9 +10,6 @@ >> #define _ASM_ARC_PCI_H >> >> #ifdef __KERNEL__ >> -#include >> -#include >> - >> #include >> >> #define PCIBIOS_MIN_IO 0x100 >> -- >> 1.8.1.5 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Remove the inclusion of pci-bridge.h and pci-dma-compat.h
On Tue, Mar 15, 2016 at 11:06:02AM +, Joao Pinto wrote: > While building linux-next the test robot detected that the pci.h was including > two removed header files (pci-dma-compat.h and pci-bridge.h) causing the > process to fail: > http://lists.infradead.org/pipermail/linux-snps-arc/2016-March/000711.html > > This patch has the goal to fix the build problem. > > Signed-off-by: Joao Pinto Thanks, Joao, I folded this fix into the original commit. I should have caught this myself, since I'm the one who removed pci-bridge.h. > --- > arch/arc/include/asm/pci.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/arc/include/asm/pci.h b/arch/arc/include/asm/pci.h > index 2f2011c..ba56c23 100644 > --- a/arch/arc/include/asm/pci.h > +++ b/arch/arc/include/asm/pci.h > @@ -10,9 +10,6 @@ > #define _ASM_ARC_PCI_H > > #ifdef __KERNEL__ > -#include > -#include > - > #include > > #define PCIBIOS_MIN_IO 0x100 > -- > 1.8.1.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Don't source drivers/pci/pcie/Kconfig ourselves
On 3/15/2016 11:38 AM, Vineet Gupta wrote: > On Tuesday 15 March 2016 04:47 PM, Andreas Ziegler wrote: >> Commit 5f8fc43217a0 ("PCI: Include pci/pcie/Kconfig directly from >> pci/Kconfig") in linux-next changed drivers/pci/Kconfig to include >> drivers/pci/pcie/Kconfig itself, so that architectures do not need >> to source both files themselves. ARC just recently gained PCI support >> through commit 6b3fb77998dd ("ARC: Add PCI support"), but this change >> was based on the old behaviour of the Kconfig files. This makes >> Kconfig now spit out the following warnings: >> >> drivers/pci/pcie/Kconfig:61:warning: choice value used outside its choice >> group >> drivers/pci/pcie/Kconfig:67:warning: choice value used outside its choice >> group >> drivers/pci/pcie/Kconfig:74:warning: choice value used outside its choice >> group >> >> This change updates the Kconfig file for ARC, dropping the now >> unnecessary 'source' statement, which makes the warning disappear. >> >> Signed-off-by: Andreas Ziegler > > Thx for the fix Andreas. > > @Bjorn sorry you might to have to pick this one up as well. > If not, that's fine too - I'll queue it up once ARC PCI hits upstream. > > Thx, > -Vineet > >> --- >> arch/arc/Kconfig | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig >> index 69d05f5..282efec 100644 >> --- a/arch/arc/Kconfig >> +++ b/arch/arc/Kconfig >> @@ -592,7 +592,6 @@ config PCI_SYSCALL >> def_bool PCI >> >> source "drivers/pci/Kconfig" >> -source "drivers/pci/pcie/Kconfig" >> >> endmenu >> > Acked-by: Joao Pinto ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Don't source drivers/pci/pcie/Kconfig ourselves
On Tuesday 15 March 2016 04:47 PM, Andreas Ziegler wrote: > Commit 5f8fc43217a0 ("PCI: Include pci/pcie/Kconfig directly from > pci/Kconfig") in linux-next changed drivers/pci/Kconfig to include > drivers/pci/pcie/Kconfig itself, so that architectures do not need > to source both files themselves. ARC just recently gained PCI support > through commit 6b3fb77998dd ("ARC: Add PCI support"), but this change > was based on the old behaviour of the Kconfig files. This makes > Kconfig now spit out the following warnings: > > drivers/pci/pcie/Kconfig:61:warning: choice value used outside its choice > group > drivers/pci/pcie/Kconfig:67:warning: choice value used outside its choice > group > drivers/pci/pcie/Kconfig:74:warning: choice value used outside its choice > group > > This change updates the Kconfig file for ARC, dropping the now > unnecessary 'source' statement, which makes the warning disappear. > > Signed-off-by: Andreas Ziegler Thx for the fix Andreas. @Bjorn sorry you might to have to pick this one up as well. If not, that's fine too - I'll queue it up once ARC PCI hits upstream. Thx, -Vineet > --- > arch/arc/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig > index 69d05f5..282efec 100644 > --- a/arch/arc/Kconfig > +++ b/arch/arc/Kconfig > @@ -592,7 +592,6 @@ config PCI_SYSCALL > def_bool PCI > > source "drivers/pci/Kconfig" > -source "drivers/pci/pcie/Kconfig" > > endmenu > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Don't source drivers/pci/pcie/Kconfig ourselves
Commit 5f8fc43217a0 ("PCI: Include pci/pcie/Kconfig directly from pci/Kconfig") in linux-next changed drivers/pci/Kconfig to include drivers/pci/pcie/Kconfig itself, so that architectures do not need to source both files themselves. ARC just recently gained PCI support through commit 6b3fb77998dd ("ARC: Add PCI support"), but this change was based on the old behaviour of the Kconfig files. This makes Kconfig now spit out the following warnings: drivers/pci/pcie/Kconfig:61:warning: choice value used outside its choice group drivers/pci/pcie/Kconfig:67:warning: choice value used outside its choice group drivers/pci/pcie/Kconfig:74:warning: choice value used outside its choice group This change updates the Kconfig file for ARC, dropping the now unnecessary 'source' statement, which makes the warning disappear. Signed-off-by: Andreas Ziegler --- arch/arc/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 69d05f5..282efec 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -592,7 +592,6 @@ config PCI_SYSCALL def_bool PCI source "drivers/pci/Kconfig" -source "drivers/pci/pcie/Kconfig" endmenu -- 1.9.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Remove the inclusion of pci-bridge.h and pci-dma-compat.h
On Tuesday 15 March 2016 04:36 PM, Joao Pinto wrote: > While building linux-next the test robot detected that the pci.h was including > two removed header files (pci-dma-compat.h and pci-bridge.h) causing the > process to fail: > http://lists.infradead.org/pipermail/linux-snps-arc/2016-March/000711.html > > This patch has the goal to fix the build problem. > > Signed-off-by: Joao Pinto Acked-by: Vineet Gupta @Bjorn since the ARC PCI support is still not upstream, and was slated to go via you, please pick this one up as well. Thx, -Vineet > --- > arch/arc/include/asm/pci.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/arc/include/asm/pci.h b/arch/arc/include/asm/pci.h > index 2f2011c..ba56c23 100644 > --- a/arch/arc/include/asm/pci.h > +++ b/arch/arc/include/asm/pci.h > @@ -10,9 +10,6 @@ > #define _ASM_ARC_PCI_H > > #ifdef __KERNEL__ > -#include > -#include > - > #include > > #define PCIBIOS_MIN_IO 0x100 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] Remove the inclusion of pci-bridge.h and pci-dma-compat.h
While building linux-next the test robot detected that the pci.h was including two removed header files (pci-dma-compat.h and pci-bridge.h) causing the process to fail: http://lists.infradead.org/pipermail/linux-snps-arc/2016-March/000711.html This patch has the goal to fix the build problem. Signed-off-by: Joao Pinto --- arch/arc/include/asm/pci.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arc/include/asm/pci.h b/arch/arc/include/asm/pci.h index 2f2011c..ba56c23 100644 --- a/arch/arc/include/asm/pci.h +++ b/arch/arc/include/asm/pci.h @@ -10,9 +10,6 @@ #define _ASM_ARC_PCI_H #ifdef __KERNEL__ -#include -#include - #include #define PCIBIOS_MIN_IO 0x100 -- 1.8.1.5 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: axs10x - add Ethernet PHY description in .dts
Following commit broke DW GMAC functionality on AXS10x boards: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763 That's what happens on eth0 up: --->8 libphy: PHY stmmac-0: not found eth0: Could not attach to PHY stmmac_open: Cannot attach to PHY (error: -19) --->8 Simplest solution is to add PHY description in board's .dts. And so we do here. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Phil Reid Cc: David S. Miller Cc: linux-ker...@vger.kernel.org Cc: net...@vger.kernel.org Cc: sta...@vger.kernel.org # 4.5.x --- arch/arc/boot/dts/axs10x_mb.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi index 44a578c..04b999e 100644 --- a/arch/arc/boot/dts/axs10x_mb.dtsi +++ b/arch/arc/boot/dts/axs10x_mb.dtsi @@ -47,6 +47,14 @@ clocks = <&apbclk>; clock-names = "stmmaceth"; max-speed = <100>; + mdio0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + phy0: ethernet-phy@0 { + reg = <1>; + }; + }; }; ehci@0x4 { -- 2.5.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/4 v3] drm: Add support of ARC PGU display controller
On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote: > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote: > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote: > > > +static int arcpgu_atomic_commit(struct drm_device *dev, > > > + struct drm_atomic_state *state, bool async) > > > +{ > > > + return drm_atomic_helper_commit(dev, state, false); > > Note that this isn't really async if you ever get around to implement > > fence support or vblank support. Just fyi. > > Ok but for now should I leave it as it is? Yeah ok as-is, hence just fyi. > > > +static struct drm_driver arcpgu_drm_driver = { > > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | > > > + DRIVER_ATOMIC, > > > + .preclose = arcpgu_preclose, > > > + .lastclose = arcpgu_lastclose, > > > + .name = "drm-arcpgu", > > > + .desc = "ARC PGU Controller", > > > + .date = "20160219", > > > + .major = 1, > > > + .minor = 0, > > > + .patchlevel = 0, > > > + .fops = &arcpgu_drm_ops, > > > + .load = arcpgu_load, > > > + .unload = arcpgu_unload, > > Load and unload hooks are deprecated (it's a classic midlayer mistake). > > Please use drm_dev_alloc/register pairs directly instead, and put your > > device setup code in-between. Similar for unloading. There's a bunch of > > example drivers converted already. > > Ok I took "atmel-hlcdc" as example. > And that's interesting. > > If I put my arcpgu_load() in between drm_dev_alloc() and > drm_dev_register() then I'm getting this on the driver probe: > -->8--- > [drm] Initialized drm 1.1.0 20060810 > arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab > [ cut here ] > WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 kobject_add_internal+0x17c/0x498() > kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0) > Modules linked in: > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17 > > Stack Trace: > arc_unwind_core.constprop.1+0xa4/0x110 > warn_slowpath_fmt+0x6e/0xfc > kobject_add_internal+0x17c/0x498 > kobject_add+0x98/0xe4 > device_add+0xc6/0x734 > device_create_with_groups+0x12a/0x144 > drm_sysfs_connector_add+0x54/0xe8 > arcpgu_drm_hdmi_init+0xd4/0x17c > arcpgu_probe+0x138/0x24c > platform_drv_probe+0x2e/0x6c > really_probe+0x212/0x35c > __driver_attach+0x90/0x94 > bus_for_each_dev+0x46/0x80 > bus_add_driver+0x14e/0x1b4 > driver_register+0x64/0x108 > do_one_initcall+0x86/0x194 > kernel_init_freeable+0xf0/0x188 > ---[ end trace c67166ad43ddcce2 ]--- > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -2 > arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs > arcpgu: probe of e0017000.pgu failed with error -2 > -->8--- > > But if I move arcpgu_load() after drm_dev_register() then everything > starts properly and I may see HDMI screen works perfectly fine. > > Any thoughts? Oops, yeah missed that detail. If you look at atmel it has a loop to register all the drm connectors _after_ calling drm_dev_register(). Totally forgot about that. Can you pls - Extract a new drm_connector_register_all() function (atmel_hlcdc_dc_connector_plug_all seems to be the best template), including kerneldoc. - Adjust kerneldoc of drm_dev_register() to mention drm_connector_register_all() and that ordering constraint. - Roll that helper out to all the drivers that currently hand-roll it (one patch per driver). I know a bit of work but imo not too much, and by doing some small refactoring every time someone stumbles over a drm pitfall we keep the subsystem clean&easy to understand. You're up for this? Would be a prep series, I'll happily review it to get it merged fast. Just a few weeks ago I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy ones all over the subsystem, in other words: You'll have my full attention ;-) > > > + .dumb_create = drm_gem_cma_dumb_create, > > > + .dumb_map_offset = drm_gem_cma_dumb_map_offset, > > > + .dumb_destroy = drm_gem_dumb_destroy, > > > + .get_vblank_counter = drm_vblank_no_hw_counter, > > > + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > > > + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, > > > + .gem_free_object = drm_gem_cma_free_object, > > > + .gem_vm_ops = &drm_gem_cma_vm_ops, > > > + .gem_prime_export = drm_gem_prime_export, > > > + .gem_prime_import = drm_gem_prime_import, > > > + .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, > > > + .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, > > > + .gem_prime_vmap = drm_gem_cma_prime_vmap, > > > + .gem_prime_vunmap = drm_gem_cma_prime_vunmap, > > > + .gem_prime_mmap = drm_gem_cma_prime_mmap, > > > +}; > > > + > > > +static int arcpgu_probe(struct platform_device *pdev) > > > +{ > > > +